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ABSTRACT 


The U.S. Army lacks a single automated fire support system. The goal of Army’s 
ongoing project of Advanced Field Artillery Tactical Data System (AFATDS) is to 
integrate all of its fire power under a single automated system to provide an efficient fire 
support in the battlefield. AFATDS is being implemented using the language ADA for 
battalion and above level. The problem for this research is to implement AFATDS for 
battalion (just for technical fire direction) level and below. In addition, we want to add a 
Graphical User Interface (GUI), use modern software engineering principles and add 


multitasking. 


The approach taken was to apply object-oriented paradigm for the design and 
development of the battery level of AFATDS using Microsoft Windows’ operating 
environment which provides (non-preemptive) multitasking and a GUI, and Borland C++ 


as the development tool. 


The results are as follows: The battery level software of AFATDS 1s implemented. The 
GUI provided a better interface which facilitates easier training [Ref. 17]. Multitasking 
allowed multiple firing missions to execute concurrently which was not possible with BCS. 
Object-oriented features of Borland C++ provided 60% improvement for GUI development 


than traditional programming languages. 
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I. INTRODUCTION 


A. BACKGROUND 


The mission of artillery is to provide and coordinate devastating fires, giving the 
maneuver commander the overwhelming combat power to win decisively and quickly 
anywhere and any time. Modern artillery has improved its effectiveness using new 


technologies with weapon and C’I systems. 


Technology developments, productivity, and battlefield concepts always force C’I 
components to work in an integrated environment to attain victory in the warfare. The 
current leading field artillery tactical automated system essentially based on TACFIREs/ 
LTACFIREs which are battalion level systems. The sub-systems of a TACFIRE/ 
LTACFIRE are Battery Computer Systems (BCSs) and various interfaces. It is an isolated 
system from other automated systems and services. Next Step is to integrate all the tactical 
data systems of the army, namely Army Command and Control System (ACCS). Field 
Artillery Tactical Data System will be the subsystem of ACCS. 


Advanced Field Artillery Tactical Data System (AFATDS) which is an ongoing 
project being a sub system of ACCS 1s aimed to realize artillery portion of the integration. 
Since AFATDS had not been fielded yet, the concept of FATDS 1s preferred for the same 
scope of AFATDS for this thesis research. This integration will provide: 


¢ Centralized database which aims dumping databases to other computers to provide 
backup, exchanging data between relevant nodes and reducing data redundancy. 


¢ Faster fire support. 
¢ Saving resources. 
Field Artillery Tactical Data System (FATDS) is composed of several layers and 
independent interfaces. Layers are: 


¢ Battery level 
¢ Battalion level 


¢ Corps level 


Interfaces are: 
¢ Digital message devices 
¢ Screens 
No matter how modern armies prepare themselves for future conflicts, there will be 
always surprises and unconditional requirements. Reprogrammability of automated 
systems provides flexibility to new requirements of a battlefield. At this point software part 
of automated systems needs programming paradigms which provide high degree of 
software engineering goals which are: [Ref.21: p.65] 


¢ Modifiability: The software system should be easily modifiable without causing other 
errors or complexity. 


¢ Efficiency: The software system should operate using the set of available resources, 
which are time and space, in an optimal manner. 


¢ Reliability: The software system should operate for long periods of time without human 
intervention. 


¢ Understandability: /t is essential for modification and project management because of 
the need for coordination. 


In addition to those goals software developers have been experimenting with various 
methodologies to achieve some of the following goals: [Ref.18: p.16] 


¢ Precise specification of the design. 
¢ Shorter code development phase. 

¢ Easier development of code. 

¢ Reusability of code. 


I. Advanced Field Artillery Tactical Data System 


AFATDS is an ongoing project for total fire support system for U.S. Army, with 
its fielding in FY’95. AFATDS will align targets with fire units and munitions and help 
manage survey and meteorological operations, movement and positioning and process of 
managing logistics. AFATDS will take into account all available fire support means, to 
include attack helicopters, tactical air, naval gunfire and offensive electronic warfare. It 


will employ sophisticated routines to recommend the right systems for the targets under 


analysis and facilitate the synergistic integration of efforts. The heart of AFATDS’ 


development is software. 


The heart of AFATDS’ development has been the software. The first step in the 
AFATDS program was to establish the command and control functions of the fire 
support system, a detailed analysis that identified the inputs, the processes and the 
outputs. The results of this analysis have driven the AFATDS software. [Ref.23: p.39] 


Major advantages of AFATDS in terms of software and hardware are seen as: 
[Ref.23: p.39-41] 
¢ Easy upgrades 
¢ No more Mutual Support Units (MSUs) 
¢ Comprehensive Functionality 
¢ Interoperability 
¢ No AFATDS military occupational speciality (MOS) necessary 
¢ Common hardware Army-wide 
¢ Large screen display 
¢ No more dedicated shelters 
¢ Fire Support Elements (FSEs) linked from battalion through corps 
¢ Lab-Top computers for Fire Support Officers (FSOs) and commanders 
A key aspect of AFATDS software will be its interoperability. As a component of 
ACCS, AFATDS will interface with maneuver, intelligence, air defence and combat 
service support systems. It is also being designed to interface with the Air Force and Marine 
automated systems and with the German (Adler) and British (BATES) systems. These 


interfaces will significantly enhance the total integration of the joint and combined team. 


[Ref.23: p.40] 


AFATDS has a distributed database architecture. The database of each AFATDS 


node will be maintained continually with the latest information. 


To maintain a full integration, portability and easy maintenance, AFATDS is 


using DoD’s standard programming language, ADA. AFATDS is conceptually evaluated 


in 1989 and scheduled to be completed in FY ’93 with fielding to the total force scheduled 
for FY 95. 


2. Battery Computer System 


BCS is defined as follows: 


An automated data processing system located in the firing battery. It consist of three 
major components: the battery computer unit, the power distribution unit, and 1 to 12 
gun display units. It is used to compute accurate firing data and as digital 
communications interface. [Ref.10: Glossary-2] 


3. Motivation for Object-Oriented Approach 
My motivation for O-O approach in general: 


¢ Object-oriented approaches encourages the use of modern software engineering 
technology. 


¢ Object-oriented approaches promote and facilitate software reusability. 
¢ Object-oriented approaches facilitate interoperability. 


¢ When done well, object-oriented approaches produce solution which closely resemble 
the original problem. 


¢ When done well, object-oriented approaches result in software which is easily 
modified, extended, and maintained. 


¢ Object-orientation improves traceability. 


¢ Object-orientation improves the conceptual integrity of both the process and the 
product. 


B. OBJECTIVES - 


The objective of this thesis is to create the battery level software of Field Artillery 
Tactical Data System analyzing the benefits of object-oriented implementation of both 
programming and database of the project in an environment which provides multitasking 


and graphical user interface. 


C. ORGANIZATION 


Chapters are organized into two groups: Programming language and database. Chapter 


IT evaluates Object-Oriented Programming development languages and tools briefly. 


Chapter III addresses the design features of programming phase. Chapter IV is a 
comparison of the Object-Oriented language implementation of subject vs. conventional 
programming languages. Chapter V evaluates the possible database management options 
for FATDS. Chapter VI addresses the design of the selected database management option. 


Conclusions and future works on FATDS are summarized in Chapter VII. 


Il. THE PROGRAMMING ENVIRONMENT, LANGUAGE AND APPLICAITON 
DEVELOPMENT TOOLS FOR FATDS 


The concept of Object-Orientation may not give any idea about its performance over 


other paradigms without considering programming environment, language and application 


development tools.! For this research I have chosen PC-based Microsoft Windows 3.1 as 
the programming environment, C++ as the Object-Oriented Language (OOL), and Borland 
C++ & Application Framework as the application development tools. Since the purpose of 
this research is to focus on the programming performance benefits of object-oriented 
implementation, the best selection of those elements is not discussed. 

Object-Oriented Design (OOD) and Object-Oriented Analysis (OOA) of FATDS will 
be discussed on the next chapter. Following sections discuss the characteristic of the 


selected elements. 
A. PROGRAMMING ENVIRONMENT 


When it comes to portability issue of a software, there are questions to be answered 
about programming environment. What will the application be used for? What kind of 
terminals will be used? Who will be the users? Which operating system will the application 
work on? What kind of devices will the application work with? Will the application work 
stand-alone or in networked environment? Does the application have to work with 
heterogenous subsystems in an network? There are many questions that a programmer 
faces with. I have taken PCs as the main hardware unit. Table | displays the system 


requirements of the O-O FATDS. The reasons for selections this environment are: 


¢ In addition to technologic developments, economical and administrative obligations 
makes all the uniform systems heterogenous. Especially huge systems do not tend to 
keep themselves uniform. PCs are unique examples to represent the variety of users, 
hardwares and software. Though its heterogeneous structure creates some problems - 
like training, hardware, software maintenance, either single or in a networked media 


1. When an object-oriented system is under construction, the architecture is foremost in impor- 
tance, just as it is in all other engineering disciplines. The development process is adapted to the 
architecture, and the tools are adapted to the process. [Ref.15: p.26] 


PCs are forcing companies to pay more attention to them. PCs word is developing with 
its new features and object-orientation is claimed for being familiar with these 
complexity. 


¢ PCs are more available computers to ordinary people. This means more people are 
familiar with PCs (which is important from the user’s train point of view) and there are 
sophisticated application tools for PCs too. 


¢ Its software and hardware are more economical than work stations. 
¢ This selection satisfies the objective of this research. 


TABLE 1: SYSTEM REQUIREMENTS OF O-O FATDS 


Application Application 
Development,,jin, developmentoptimal 
Display VGA, 2 color SVGA, 256 color 


MS-DOS 5.0 & MS- MS-DOS 5.0 & MS- 
Windows 3.1 Windows 3.1 











2 MB RAM 8 MB RAM 
80 MB 120 MB 





1. Hardware Basics 


Hardware capabilities may boost the performance of the application, but there is 
no direct relation with the programming style for this research. Board, CPU, caching, 
display and other I/O devices have direct relations with either operating system or 


application requirements. 
2. Windows Basics 


The general structure of Windows programming naturally fits the OOP style. 
Everything on the screen is defined as a window, because each object has to have some 
common features. Each window inherits some of its features from other windows and add 


some specific ones. The data goes with a window is encapsulated into the window object. 


Window objects are polymorphic, they can all receive common messages and take action 


that is appropriate for that window. [Ref.25: p.4}] 


a. The GUI 


Does a user, who is Supposed to use a computer, have to learn what the 
computer is? Or, should the computer be designed regarding a specified user group? 
Practically both questions have positive answers. Needs and technology determine each of 
its ratio In an application. 

Most computer users are familiar with Windows’ GUI and all Windows 
applications have consistent interface. Consistency 1s one of the important factors which 
helps a user to adopt a new application in shorter time. 

Though every environment provides different GUI in different degrees of 
graphicism Windows provides all the basic GUI tools. These are the most common 
graphical elements: 


¢ Icons 
¢ Fonts and text formatting 
¢ Charts and graphics 
¢ Menus 
One of the graphical elements of Windows Application Interface (API) is 


controls which represents an event or information source for events. Controls are mainly 
used for user input. The leading feature of controls is to make the user remember some 
information but not to memorize for recalling. The controls are: 


¢ Buttons 
¢ Check boxes 
¢ Combo boxes 
¢ Static/dynamic edit fields 
¢ Radio buttons 
¢ Custom controls 
There are high level graphical elements too: 


¢ Drag-and-drop mechanism 
¢ Hot spots in text or graphics to do something when selected. 


Those were the just the elements of Windows GUI. The problem is to produce 


something that the user will understand and use it easily. 


b. Event-Driven Applications 

The only communication link between a user and a terminal is Input / Output 
(I/O) actions. Procedural interfaces provide I/O in either command line or question-and- 
answer form. In either case, the application gets some input, goes off to process it, and 
produces output. The application is the boss, and the user acts as an intelligent database 
server. Menu-driven applications takes some database burden of the user. [Ref.17: p.39] 

Event-driven applications act on events coming from a variety of sources. 
The events may come from controls that the user can activate, from other programs, or from 
devices such as the clock or communications port. 

Event-driven applications are not specific only to Windows, but almost all 
Windows applications are based on this style. Event-driven programming brings a different 
approach to the design and implementation of an application. Events leads the way, so 
establishing a GUI generally is the first phase of implementation. Just a GUI, without a real 
code behind it, serves as a prototype of the application. This eliminates other third party 


tools for rapid code prototyping. 


c. Multitasking 
Windows 3.1 provides a non-preemptive multitasking environment. This 
feature is one of the key factor for the end-user. The user can run more than one application 


simultaneously. 


d. Device Independence 
This feature is important for both user and programmer. The device 
dependency is hidden away in the Windows’ Graphics Device Interface (GDI) and deice 


drivers that are either bundled with the retail Windows or supplied by the device 


manufacturer. Windows program developers can ignore about devices, they know that their 


application will work with all the devices that are introduced to Windows. 


For programmers in non-Windows environment, program output can be the most 
challenging task of the entire application. Idiosyncrasies of a wide variety of devices 
must be discovered, resolved, and properly handled in the code. For small developers, 
just obtaining the necessary manuals and use of devices for testing can prohibitively 
expensive Under Windows, all these problems simply goes away.[Ref.19: p.78] 


e. Elements of a Windows Application 
A typical Windows applications has these elements: A main window contains 
a title bar, menu and aclient area. The client area serves as a canvas that the application can 
draw on. Main window may have child windows. Child window looks sometimes as a 
control or sometimes another client region. Dialog boxes are for either information display 
or input purposes. Dialog boxes contain a number of controls, such as buttons, radio boxes, 


CIC. 


f. Dynamic Link Libraries (DLL) 

DLLs are one of the advanced features of Windows. Normally most functions 
have been statically linked to applications. When a hbrary or object code is used the 
executable versions of the functions contained in the code are brought in to executable file. 
[Ref.20: p.48] Since this is a static linking, multiple versions of the same function may exist 
in the executable file. Any modification on the library functions require relinking of the 
application. So the whole application is replaced. 

Dynamic linking occurs at run-time. Application is just introduced to the 
function and in which. DLL file its implementation is placed. The executable file does not 
carry the object code. When the executing program makes a call to a dynamic link function, 
Windows checks to see whether the function is already in memory. If it is in memory 
Windows increases the in-use counter for this library by one and passes execution to the 


new memory location. If the function is not already in memory, Windows tries to find a file, 
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with a.DLL extension, that contains the desired function. Windows then loads the function 
into memory. {Ref.20: p.49] 

The only disadvantage of DLLs is that .DLL files should be ported with the 
application while the advantages of DLLs are: 


¢ Downsize the executable code size and compile-link time. E.g., OFIRE.EXE file was 
more than 400K lon before using .DLLs, and it become almost 150K long executable 
file. 


¢ Provide the application to run on computers that have a limited amount of memory. 


¢ Ease the maintenance of the code. When a DLL file is updated, it is enough to replace 
that .DLL file without linking the whole code. 


¢ Make interchangeable modules.{Ref.25: p.66] 
B. PROGRAMMING LANGUAGE 


I have selected C++ as an OOPL. It is not the only OOPL, but it is one of the OOPLs 
that supports all the O-O features. One of the leading reasons which makes me select C++ 


is its commercially availability. 


For better or worse, the real winner today is C++, which attracts large groups of 
rogrammers at the largest companies and 1s used on thousands of projects in industry. 
iet.15: p.26] 


Stroustrup lists the language features of C++ as: 


¢ C-based, object-onented extension of C. 

¢ Class concept and class-based object-oriented paradigm. 
¢ Data abstraction and data encapsulation facilities. 

¢ Mechanism for data abstraction hierarchies. 

¢ Strongly typed. 

¢ Function and operator overloading. 

¢ User-controlled memory management. 

¢ Facilities modeling multiple inheritance. 

¢ Support polymorphism. 

¢ Type-safe linkages. 

¢ Abstract classes. 

¢ Exception handling mechanism. 

¢ Used for general purpose applications as well as simulations development. 


¢ Can be use to model conceptual solutions. 


C. APPLICATION DEVELOPMENT TOOLS 
Borland provides all the tools that is necessary to produce Windows programs. 
1. Application Development tools 


Borland C++ 3.1 and Application Framework has the following tools: 


¢ An ANSI C and C++ global optimizing compiler 

¢ A DOS protected-mode interface (DPMI) compiler and programmer’s platform 
¢ A Windows-base integrated development environment (IDE) 

¢ A graphical source browser (ObjectBrowser) 

¢ A utility for tacking Windows messages (WinSight) 

¢ A debugger for DOS and Windows applications (Turbo debugger) 

¢ A profiler for DOS and Windows (Turbo Profiler) 

¢ The Turbo Assembler 

¢ The Resource Workshop 


¢ A library of C++ classes to simplify Windows application development 
(ObjectWindows) 


¢ The EasyWin library for porting DOS programs to Windows 
¢ The Turbo Vission application framework for DOS applications 
¢ Source code to the runtime library 


2. Language 


Borland compiler runs in protected mode, so large programs and libraries do not 
require extensive swapping. Precompiled header are supported. Because the headers for 
Windows programs tend to be quite large (windows.h alone is over 120K), this Borland 


C++ feature can increase compile times by a factor of ten.[Ref.19: p.xvili][Ref.25: p.5] 


Borland IDE editor provides to open multifiles simultaneously as well as large 


files. 


I. OBJECT-ORIENTED PROGRAMMING DESIGN OF FATDS 


A. INTRODUCTION 


Object-oriented programming should follow Object-Oriented Analysis (OOA) and 
Object-Oriented Design (OOD). Though O-O paradigm goes back two decades, OOA and 
OOD methodologies are not mature enough. [Ref.14: p.22] Discussions are still continuing 
about a perfect methodology for both OOA and OOD. The goal of OOA is still the same: 
the development of an accurate and complete representation of the problem domain. 
[Ref.14: p.26] The problem is that there is no standard OOA methodology. I have selected 
Coad & Yourdon OOA [Ref.6] and Booch OOD [Ref.4] to build basis for O-O 


methodologies of this research. 
1. Coad and Yourdon OOA 


This model defines the problem domain in five consecutive steps where each step 
builds on the previous step. The steps are:[Ref.14: p.27] 
¢ Define objects and classes: Look for structures, other systems, devices, events, roles, 
operational procedures, sites, and organizational units. 


¢ Define structures: Look for relationship between classes and represent them as either 
general-to-specific Structures. 


¢ Define subject areas: Examine top level objectives within whole-to-part hierarchies and 
mark these as candidate subject areas. Refine subject areas to minimize 
interdependencies between subjects. 


¢ Define attributes: Identify the atomic characteristics of objects as attributes of the 
object. Also look for associative relationships between objects and determine the 
cardinality of those relationships. 


¢ Define services: For each class and object, identify all the services it performs, either 
on its own behalf or for the benefit of other classes and objects. 


Coad and Yourdon uses the following tools for OOA: 


¢ Class and object diagram 
¢ Object state diagram 
¢ Service chart 
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2. Booch OOD 


Booch is the pioneer of OOD. Booch’s methodology was originally ADA 
language specific, but he adopted his methodology to O-O completely. He recommends not 
a specific ordering of analysis plus design phases. The strategy should be “analyze a little, 
design a little” [Ref.4: p.201]. Because there is no certain border between analysis and 
design of a problem to jump from one to another. Design process should be worked with 
iteratively and incrementally, augmenting formal diagrams with informal techniques 
appropriate to the problem at hand. Booch’s four major design steps are [Ref.14: p.32]: 

¢ Identify classes and objects: /dentify key abstractions in the problem space and label 


them as candidate classes and objects. 


Identify the semantics of classes and objects: Establish the meaning of the classes and | 
objects identified in the previous Step using a variety of techniques, including creating 
“scripts” that define the life cycles of each object from creation to destruction. 


Identify relationships between classes and objects: Establish class and object 
interactions, such as patterns of inheritance among classes and pattern of cooperation 
among classes and patterns of cooperation among objects. This step also captures 
visibility decisions among classes and objects. 


Implement classes and objects: Construct detailed internal views of classes and objects, 
including definitions of their of their various behaviors (services). Also, allocate 
objects and classes to modules. 


@ 


@ 


Booch uses the following tools for OOD: 


® 


Class diagrams and class templates 


@ 


Object diagrams and timing diagrams 


State-transitions diagrams 


operation templates 


e 


module diagrams and templates 


® 


process diagrams and templates 


3. My OOA and OOD Strategy 


As itis indicated above I carried out analysis and design together. The reasons are: 


e 


There is no distinct border between analysis and design. Switching to design to late may 
Cause waste of resources while switching too early may cause not to identify the 
problem. It is more flexible to do them together. 
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The design may not reflect the capabilities of the system environment or the 
requirements of the user completely. Instead of using external software prototyping 


tools, GUI-based prototyping which could be performed at various steps of system 
development, provides realistic and early evolution of the design. Each time after 
receiving feed-backs from the consumer, it could be necessary to modify the analysis 
again. 


¢ There are diverse design options for the project. Not all the design options are derived 
from the analysis. At a point in the project it would be necessary to modify the design 
and the analysis process as well. 


¢ There may appear some constraints and force to change to alternate designs. E.g., size 
of code may force the system hardware’s memory limitations. 


Above conditions are valid not only for O-O methodologies, but also for non- 
object-oriented ones. After evolution of a system, if a modification is required, then it will 
be necessary: 


¢ To add a/some new part(s) into the system and/or, 
¢ To throw away a/some part(s) of the system and/or, 
¢ To modify a/some part(s) of the system 


Object-oriented systems adds another option for creation or modification of a 
system: Reuse. At the beginning of a large project development or on small projects the role 
of reusing may not be so important, but during the development of phase and for large 
scaled projects reusing begins to save resources. Assuming that old components of the 
system are well tested, other objects which are created by inheriting those old objects are 


most likely be trusted objects. It will take shorter time to test new objects. 


First product after a brief analysis was the GUI of the project. The design of GUI 
is an application-independent technology for which a number of useful libraries of reusable 
software Components have been developed. So, GUI’s development was faster than the 
applications. FIGURE | on page 16 show the cycles for O-O FATDS project development. 
This cycle is named as Model-Based Project Development Cycle (MBPDC). The 
product(s) 1s always tested with the real-life requirements during the development cycle, 
even though the product(s) is not a complete one during the process. First analysis helps to 
form classes and objects to create the first form of the product which is just the GUI. 


Modeling and testing begins with this GUI which serves as a prototype. This is more than 


a usual prototype which simulates a real-life application, but it 1s the real-life application. 


Modeling leads the design, so the analysis. 


Design 


of 
Se RO RI CSR ee a ke nS 





Figure 1: Model-based project development cycle for O-O FATDS 


There is always a working model. Functionality of the model is limited during the 


development cycle and it completely matures at the end of the MBPDC. 


The nature of event-driven programming and its compatibility with OOP helps to 
establish separate or independent event modules. This event inter-independency and 


reusing makes the modification easier at any time of MBPDC. 
4. Naming Conventions 


For a more readable code I have used long meaningful names for variables, 


enumeration types, classes, and objects etc. E.g., SubFireCallWndCls and RadioGrid. 
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I have also embedded small identifiers into the names to distinguish them from 
others. In addition, I named an instance of a type or class almost the same with its 
instantiator, e.g., SubFireCallWndCls is a class type and SubFireCallWnd is instance of 
that class. Table 2 on page 17 displays a list of embedded codes which are used for naming 


in this research. 
TABLE 2: EMBEDDED CODES FOR NAMING 


*Cls Class defination 
*DlgCls Dialog window class defination 


*Dlg 
*WndCls 
*wnd 
Button* 
Check* 
Combo * 


Edit * 


Dialog object 

Window class defination 
Window object 

Button control object 
Check box control object 
Combo box control object 
Edit control object 


List* List box control object 

Radio* Radio box control object 
Any kind of object handler 
Identifier for window objects 
Enumeration type definition 





B. ANALYSIS 
1. FATDS System Requirements 


FIGURE 2 on page 18 displays a block diagram for Firing Support (FS) portion 
of FATDS. The basic function of the system is to make the guns fire with computed data 


against the targets on the battlefield which are asked from artillery to be destroyed. 
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Target acquisition elements 
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<< s 
i 
Fire commands 


Command and Control Centers Fire Orders 
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Gun and ammo status 


Survey elements 





Figure 2: Block diagram for Field Artillery Tactical Data System / FS 


Each of the block elements could represent more than one of that element and in 
diverse organizational structures. The automation of the each structure may differ too. 
Regarding the communication tools of any kind and battlefield irregularity, the system 
Should keep to work with acceptable functionality. The major system elements are: 


¢ Guns: They are organized in platoons, batteries or battalions as basic firing units. The 
number of guns and models of them vary. 


¢ Fire direction centers: The element of a command post consisting of gunnery and 
communication personnel and equipment by means of which the commander exercises 


fire direction and/or fire control. The fire direction center receives target intelligence 
and requests for fire and translates them into appropriate fire direction [Ref.11: p.G- 
8]. FDCs are functional at platoon, battery and/or battalion levels. 


@ 


Target acquisition elements: There are various target acquisition elements. FA 
battalion S2, targeting officer, fire support team, aerial fire support observers, combat 
observation/lasing team, survey platoon, weapons-location radar, moving-target- 
locating radar and electronic warfare are all the elements for target acquisition.[Ref.7: 
p5-1] 


Command and control elements: From Fire Direction Officer (FDO) at platoon | 
battery level to higher tactical headquarter who plans and controls the fire are included 
in this block. Their role is tactical rather than technical. These elements make decisions 
about “Who will fire?” , “Which target(s) will be fired?” , “What kind of weapon(s) & 
ammunition(s) combination will be formed?” , “When will be the firing time? Different 
levels of command may have different control responsibilities on various operations. 


¢ Survey elements: These are technical elements too. Survey elements provides met 
messages, target intelligence, and land survey support for the FDC and command 
control elements. 


Database: Local or centrally located, distributed or single database system 1s the main 
information source of the system. To avoid waste of resources, central databases are 
encouraged. 


¢ Timer: This is just a control element which Sets the timed fires or other events. All the 
elements should follow a central time function for synchronization. 
The following inputs exists: 


¢ Fire call 

¢ Fire order 

¢ Fire commands 

¢ Fire orders 

¢ Firing reports 

¢ Firing table 

¢ Gun and ammo status 
¢ Message to observer (MTO) 
¢« Met messages 

¢ Subsequent fire calls 
¢ Status reports 

¢ Subsequent fire call 

¢ Surveys 

¢ Target acquisition 

¢ Target info 

¢ Target lists 

¢ Target update 
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« Time 


2. Defining the Boundaries of the Problem 


Field Artillery Tactical Data System is sub-part of the army’s integrated 
battlefield automation program. Since this is a huge and sophisticated program this research 
has captured only Field Artillery (FA) Battery Fire Direction level regarding its FS portion. 
FIGURE 3 on page 20 displays the block diagram of battery level tactical data system/ FS. 


Battalion FDC / 
Battalion TACFIRE / LTACFIRE Observer(s) 
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Gun and ammo status 
Firing report Fire call 
Target info 


Battery FDC 


Met messages Firing results 
g Gun and ammo status 


Fire command 


Survey elements 





Figure 3: The block diagram for FATDS / FS at Battery level 
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FIGURE 4 on page 21 displays the block diagram for battery fire direction 


system. There are two major functional units, firing chart and computation. Firing chart 


Observer 


Target location info 
Fire calls 
Subsequent fire calls 






Battalion Target list Be 


Survey elements 
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Seces = | Surveys 






Chart values (range, deflection) 
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Met messages Survey elements 


Fire commands Firing report 
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Figure 4: The block diagram for battery fire direction system 


holds the coordinates of: 


¢ Batteries (gun positions) 
¢ Radars 

¢ Observation posts 

¢ Registration points 

¢ Targets 


pag 


¢ Check points 
Firing chart produces linear and angular distances of any two points, which are on 


the chart, for computation. 


After having chart values Computation transfers them into firing commands and 
sends them to the firing elements (guns). Computation reflects its computational results on 
Record of Fire (ROF) form. Computation produces the firing commands regarding: 


¢ Time: At my command, When ready, Time on Target (TOT). 


¢ Firing techniques: Surveyed firing, copperhead munition firing, nuclear munition 
firing, smoke projectile firing, illuminating projectile firing, MET+VE technique, 
registration, Fire for Effect (FFE), special corrections. 


¢ Firing tactics: Attack of large targets, target analysis, safety procedures, munition 
effects. 


¢ Ballistics (interior and exterior): Nature of propellant and projectile movement, muzzle 
velocity, meteorological conditions, dispersion. 


3. Defining the Objects and Classes 


Followings are the classes derived from the block diagram of the system and/or 
description of the diagram elements. 


¢ Dispersion 

¢ Chronometer 

¢ Fire commands 

¢ Fire Calls 

¢ Subsequent fire calls 

* Fine Onder 

¢ Message to observer 

¢ Computation 

¢ Firing report 

¢ Gun and ammo status 

¢ Target database 

¢ Firing report database 
¢ Met messages database 
¢ Guns and munitions database 
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4. Define Subject Areas 


Classes are grouped into two main subject areas: Firing chart and firing 
computation. Those groups will be the basis for the design of GUI. The classes, which have 
been formed so far, are nothing to do with GUI but they will be re-organized after the events 


of the GUI is determined. 
C. GRAPHICAL USER INTERFACE DESIGN 


So far two functional unit appeared. They will be named as OFire for firing 
computations and OCxart for firing chart manipulations. GUI design was the backbone of 
the analysis phase. They have been accomplished together. Since the GUI served as a 
prototype of the final product, it was useful determine the events for objects, classes and 


the relationships of them. 
1. Design Considerations 


The design of a GUI 1s being effected not only by the capabilities of the system’s 


environment, but also by the following criteria. 


a. The User 
Since both OChart and OFire are specific applications for a Field Artillery, 
the number of the users is limited with the FA Fire Direction Center (FDC) personnel. 
Training requirements are still one of the major issues with the user. Windows GUI 
environment eliminates some of the training problems and add these features: 


¢ The user does not have to memorize everything. He/she inputs most of the data by 
selecting, not by entering. He/she is not overloaded with decision making points at the 
same time, but he/she is asked to do only when necessary. 


¢ The GUI is forgiving for the user decisions, it is possible to take decision steps back. 
So, the system 1s less error-prone. 


¢ Even though the user knows nothing about Dos/Windows or any other OS which 
operates a window Style environment, this will help the user to adapt the software in a 
shorter time than the command line style interface. There is no certain educational 
background except reading&writing. 
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b. Consistency 
One of the most important issues with GUI is consistency. Each part of the 
applications should be consistent with: 


¢ Other issues of the user’s way of life: Button shapes and behaviors, sounds and 
graphics for warnings, etc., should be consistent with the user's daily life. 


¢ Other applications in that OS environment: The user should transfer some of herthis 
experiences from one application to other. This helps to shorthen the training and 
adaptation period, besides prevent some errors which are source from controversies. 


c. Screen-Layout Issues 
Menu system, naming terminology, semantic grouping of items, fonts and use 
of color are main points of screen-layouts. All of these factors contribute to success of a 


software, so the victory. 


d. Customizing 
To allow a user to customize an application makes easier to use that 
application in accordance with that user’s condition only. To provide standardization and 
easier adaptation of users to the applications customization is not allowed for OChart and 


OFire applications. 


e. Input and Output Devices 
Main input device for Windows applications is mouse as well as keyboard. 
Voice activated commands may be used with some limitations too. Lessening the role of 
keyboard for data entry decreases the training needs and increases the performance of the 


application 


f. On-Line help and Tutorials 
Application should feed the user with necessary information which is about 
what he/she is doing, or to do etc., at a time when he/she needs. Windows allows a standard 


style help system which is context-sensitive and topic-navigated. 
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g. Error Handling 
People are tend to make errors even if they are trained on that topic. Windows 
event-driven environment makes it easier to add check points and warnings for each 


reaction of the user. 
2. OF ire 


All the windows and dialog boxes designed for the OFire application are 


displayed on APPENDIX-D. 
3. OChart 


All the windows and dialog boxes designed for the OChart application are 
displayed on APPENDIX-D. 


D. OBJECT-ORIENTED DESIGN (OOD) 
1. Identify Classes and Objects and Their Semantics 


The classes have been formed with their actual names and grouped into 
programming modules. Not all the classes have been formed at the same time and those 


classes are the last phase of the development. 


a. The Classes for OFire 
(1) bursts.h 


e SheafWndCls 
¢ BurstsWndCls 
(2) button2.h 


¢ Button2Cls 
(3) command.h 


¢ CommandWndCls 
¢ ChronoWndCls 
¢ FireCommandsWndCls 


ASS 


¢ InfoWndCls 
¢ SubFireCallWndCls 
(4) fire.h 


¢ FireCallDlgCls 

¢ PolarWndCls 

¢ ShiftWndCls 

¢ GridWndCls 

¢ SuppressionWndCls 

¢ FireOrderDlgCls 

¢ MTODIgCls 

¢ SubFireCallDlgCls 

¢ TOTAtTimeDlgCls 

¢ TOTAfterTimeDlgCls 
(5) globals.h 


¢ ComputationCls 
(6) report.h 


¢ ReportWndCls 
¢ TextWndCls 
(7) select.h 


¢ SelectionWndCls 


b. The Classes for OChart 
(1) abslist.h 


¢ genAbstractList: Implements an abstract class of linked lists. 
(2) Chart.h 


¢ GridSetupDlgCis 

¢ TargetSetupDlgCls 

¢ GunSetupDlgCls 

¢ NewEntryDlgCls 

¢ NewFromEntryDlgCls 
¢ GunInputDlgCls 

¢ TargetInputDigCls 

¢ TargetDBDIgCls 

¢ GunDBDIlgCls 
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(3) gen2list.h 


¢ genOdList 
¢ genUdList 
(4) globals.h 


¢ GlobalCls 
(5) gundb.h 


¢ GunDBCls 
(6) info.h 


¢ SelectionToolCls 
¢ DistanceToolCls 
¢ NewToolCls 

¢ NewTToolCls 

¢ SearchToolCls 

¢ PickToolCls 

¢ InfoWndCls 

¢ ToolBarWndCls 
¢ CanvasWndCls 

(7) Targetdb.h 


¢ TargetDBCls 
2. Identify Relationship Between Classes and Objects 


FIGURE 5 on page 28 and FIGURE 6 on page 29 display the class relationships. 


In those figures system and user-defined classes are distinguishable. All the dialog or 


Aap) 


window classes which helps to develop GUI, inherit most of their behaviors from their 


parent classes. 


TSreamable TWindowsObject 





Figure 5: Class hierarchy for OFire (i) 


3. Implement Classes and Objects 


Complete listings of header files are provided on APPENDIX A and APPENDIX 
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Object TModule TApplication FireAppClis 


TControl TButton Button2Cls 





Figure 6: Class hierarchy for OFire (ii) 


E. FILE ORGANIZATION 


1. File Organization for C++ Windows Programming 


FIGURE 7 on page 30 shows a sample file organization for a a simple C++ 
Windows program. Every class is defined in a header file and its implementation is placed 
in source files. One of the exception to this rule is Main file. There are two class definitions 
for a main Windows program and a main program function. One of them inherits from 
TApplication class and it registers the instance of the application to Windows system. The 
other one inherits from TWindow or TDialog class and it creates a window for the 


application. The declarations of those classes are generally placed in Main Source File 
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since they will not be called or instantiated by anyone. Only main program functions 


instantiates them and use it.f 


Main Header File 


Main .obj File 


Main Source File 
.exe File 
Library Files 


Class Header Files | 


Class .obj File 


Class Source Files 


-d11 Files 


Resource File (. rc) .res file 





Figure 7: C++ development file organization for Windows environment 


Main Header File is used for some definitions, and dialog box class declarations. 
If some objects are placed in .DLL files, its header files are still kept like other built-in class 
libraries. The only difference for their usage is that, it should be told to the compiler the 
implementation of any class or function is placed in .DLL files. That specific. DLL file will 


only be searched during run-time. 
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Another file which is specific to Windows is resource file. It is a text file and holds 
the resource descriptions of: 


¢ Accelerators 
¢ Bitmaps 

¢ Cursors 

¢ Dialog boxes 
¢ Fonts 

¢ Icons 

¢ Menus 

¢ String tables 


Resource file can be created either manually or with Resource Workshop. It is not 
in a specific language, though it is in a special text format. Borland C++ compiler compiles 
it with a special compiler and links it to the code. All the resource code is placed in the 
executable file in separate modules. This allows the Resource Workshop application to 
open and modify the resources of an application without disturbing the executable’s 
functionality. Eliminating compile and linking efforts, this makes the maintenance easier 


from the resource point of view. 
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2. FATDS’s File Organization 


The file organization of FATDS is shown on FIGURE 8 on page 32 and FIGURE 
9 on page 33. 


fire.cpp 55an13f.db 
55an14a.db 
bursts.cpp 55an14b.db 
button2.cpp 55an14c.db 
55ani4e.db 
command.cpp 55ani 4f.db 
55ani5a.db 
dbgun.cpp 55ani6a.db 
dbtarget.cpp 55ani7a.db 
55ani8a.db 
dbtbl_f.cpp guns.db 
targets.db 


bursts.h 
button2.h 
command.h 

dbgun.h 
dbtarget.h 


dbtbi_f.h 


fire.h dialogs.cpp 


globals.h globals.cpp 


pxengine.h 


aa 
Reet OMAR RRA 
ee Reena 


report.h report.cpp 


select.h select.cpp 


paradox.h 


pdoxeng.h 
pdoxrec.h 


pdoxtab.h 


wstr.h 


bwcc.dll 
paradox.dll 


Figure 8: File organization of FATDS / FS (ofire) 
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chart.cpp 


chart.h dialogs.cpp 


gendlist.h gen2list.cpp 


gridset.cpp 
guns.db 
info.cpp targets.db 


dbtarget.h dbtarget.cpp 
dbgun.h dbgun.cpp 


abslist.h 
globals.h 


pxengine.h 


defines.h 





globals.h 
wparadox.h 


wpdoxeng.h 


wpdoxrec.h 


wpdoxtab.h 


wstr.h 


bwcec.dll 


. 





Figure 9: File organization of FATDS / FS (ochart) 


33 


F. DESIGN DECISIONS FOR DLLs 


Borland C++ and Windows both have limited number of DLL files. Each application 
adds new DLL files to the system. The more an application uses DLL files the more 


performance it provides to the user. 


DLLs, necessary for out prototype are: 
¢ Custom controls, e.g., button2. 
¢ Database engine and other database service files which works with database engine. 


G. INITIALIZATION FILES 


Some objects in the applications may need to initialize some of their attributes before 
they are created and store them back, just after they are deleted. The values of those 
attributes should be stored in a persistent environment. C++ does not provide a built-in 
database management system (it does not have to) to store such values. There are three 
options to do that: 

¢ To use a separate DBMS 


¢ To use binary files using C++’s stream libraries 
¢ To use text files using C++’s stream libraries. 
First option is not beneficial for such short amount of data. It increases the size of code 
and implementation time. Binary files store and retrieve the objects keeping their 


abstraction or their type. 


For the OChart application, it runs using the last values of which just before it is 
closed. E.g., the user will probably want to open the firing chart with the same window size, 


at the same screen location, with the same scale and customization etc., as he/she close it 
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for the last time. Each object stores these kinds of persistent data in a *.sav file. One file 


for each application is enough and it should be binary file. 


Some persistent data which is useful for customization should be stored in text files 
with *.ini extensions. These kinds of data are mostly in string type or don’t cost much to 
convert to/from other types. Its difference from *.sav files, *.ini files: 


¢ Can be edited by the user without running the application using any kind of text editor. 


¢ is useful to feed any type of control, like combo boxes and list boxes, with persistent 
data. Any object which can easily reach these data without worrying about data 
structure. 





| 
| 
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IV. COMPARISON OF OBJECT-ORIENTED VS. CONVENTIONAL 
PROGRAMMING PERFORMANCES 


A. INTRODUCTION 


As the need for the computers increases, so do the problem domain for the software. 
The software engineering goals, which are described in the first chapter, are sourced from 
the software problem. Some of the problems can be stated as [Ref.3: p.8]: 
¢ Responsiveness: Computer-based systems often do not meet user needs. 
¢ Reliability: Software often fails. 
¢ Cost: Software costs are seldom predictably and are often perceived as excessive. 


¢ Modifiability: Software maintenance is complex, costly and error-prone. 


¢ Timeliness: Software is often late and frequently delivered with less than-promised 
capability. 

¢ Transportability: Software from one system is seldom used in another, even when 
similar functions are required. 


¢ Efficiency: Software development efforts do not make optimal use of the resources 
involved (processing time and memory space). 


O-O is not a silver bullet to solve those problems, but it has important features which 
has more meaning in skillful hands. Following sections evaluates various criteria to put 


forward the compared performances of O-O against nonO-O programming environments. 
B. COMPARISON CRITERIAS 
1. Modifiability 


No software is perfect. There could be always errors. Even though a software 
meets requirements of the user, later the user will probably demand something more from 
that software. Modification is needed for two reasons: 


¢ Errors 
¢ New requirements on the software 


Modification is almost similar to fixing or modifying a car. If the system is 


complex, modification should be located on the design job first. The role of design job or 
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architecture of the system is to avoid getting lost in the complexity of the system. So the 
design should be consistent with the system. There are two step for modification: 


¢ Locating the modification point(s) in the software system 
¢ Performing the modification 


First step is mostly effected from the design tools, while the second one from 
programming language environment. The keywords for both steps are clarity and 


consistency. 


Windows programming environment provides some modification easiness of its 
own: Control tools (like buttons, string table, accelerations etc.) which can be observed 
from Borland C++ Resource Workshop, can be modified without even recompiling the 


whole software. 


The relationship between major O-O features and modification will be discussed 


on next Section. 


a. Encapsulation 


Modification may come with some extra problems like: 


¢ Increasing the complexity of the system unnecessarily 
¢ Endangering integrity of data in the modules of the software 


In C++, providing encapsulation, every object is responsible of its data and 
detail of its implementation. Mostly, objects hides their data from outer world, they just 


allow outer objects to use service or member functions to reach specific data of their own. 


b. Inheritance 


Multiple inheritance is still in dispute about whether it is a strength or move 
of a “white elephant”, in O-O world. C++ supports multiple inheritance and should be used 
carefully, since it could be a big problem for modification. All the inheritance concept 


mentioned in this research is single inheritance. 
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Suppose that FireCommandsWndcls 1s a class and has member functions of 
f1(),£2(), £3(),and soon. After a time it become necessary to make some modifications: 


changing the implementation of £1(), adding a new behavior of fnew(). 


In the conventional paradigms, modules, which does not reflects the user 


requirements, should be either: 


¢ Thrown away, since they are not functional any more: /f a replacement is required, a 
new module should be created from scratch. Old code is wasted and becomes 
completely unfunctional. 


¢ Modified: Software integrity should be preserved. Modified part of the code is lost. 
For the O-O paradigm, inheritance is another chance for reusing of the old 
code: Creating another class which inherits from FireCommandWndCls, overloading f1 () 
and having fnew() member function. Big portion of the old code is still functional and the 
rest can still be used by others. Since the old code is preserved, its reliability is preserved 


too. 
c. Polymorphism (dynamic binding) 
Consider the following sample codes derived from the OChart application: 


A base class: 


class SelectionToolCls 


{ 
Puloieie! 


virtual void DoMouseDown(long, long); 
virtual void DoMouseMove(long, long); 


); 
Child class;: 


class DistanceToolCls : public SelectionToolcls 


{ 
publie: 


Virtual void DoMouseDown(long, long); 
virtual void DoMouseMove(long, long); 
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Child class,: 


class NewToolCls : public SelectionToolCls 
{ 


pee lic: 


virtual void DoMouseDown(long, long); 
virtual void DoMouseMove(long, long); 


); 

DistanceToolCls and NewToolCls are two sample classes with their base 
class of SelectionToolCls. They all represent a button on the screen. If a user selects one 
of them then an appropniate action should take place. Those actions are the same by title 
but different by implementations. Since the interaction of the user can not be estimated in 
advance, conventional methodologies search for the user’s interaction by case-like 
statements/functions. Each time the user’s decision is wondered then it is searched. Adding 


and deleting buttons make the user to update all the case groups. 


Dynamic linking or polymorphism makes modification easier and more 


reliable than conventional paradigms. Declaring a host pointer: 


SelectionToolCls *Selection; 
DistanceToolCls DistanceTool; 
NewToolCls NewTool; 
And assigning sub-object to the pointer when needed: 
Selection = &Distance; 
OT 
Selection = NewTool; 
/.bove assignment are made after user’s interaction. Within the code: 
Selection->DoMouseMove(..); 


Or 


Selection->DoMouseDown(..); 


a) 


The pointer Selection 1s independent from address object. It will be 
bounded dynamically and will retrieve appropriate class’s virtual member function (which 
is last assigned one to the pointer). When a modification is needed, creating a new child 
class and making an assignment under a button control 1s sufficient. Polymorphism makes 


the code shorter and clear, so helps the modification. 
2. Efficiency 


The goal of efficiency implies that a software system should operate using the set 
of available resources in an optimal manner [Ref.3: p.30]. Resources are grouped into two: 


¢ Time resources 
¢ Space resources 


The use of resources is mostly dependent on hardware and the algorithm which is 
used in the software. The O-O programming paradigm does not have significant impact on 


efficiency. 
3. Reliability 


The software system should operate for long periods of time without human 
intervention. This gains more importance especially for mission-critical applications. 
Software engineers accept that there is no perfect software. The goal to minimize the 
failures which endanger the mission. For increasing reliability, OOPLs provide: 


¢ Object structure: Provides realistic mapping from real-world objects to form the 
problem domain. 


¢ Encapsulation: Protects the objects’ own privacy and provide data integrity. 


¢ Reuse of reliable objects: Assuming the old objects are well-tested, reusing of them via 
inheritance eases the testing of the new object(s). 


4. Understandability 


Understandability is essential for modification and project management, because 
of the need for coordination. Understandability is dependent upon programming language 


and tools. Language is the way to express the real-world solution [Ref.3: p.31]. 


40 


ae 


One of the fundamental differences, which distinguishes O-O from nonO-O is 
mapping from problem domain to software solutions. Conventional methodologies 
decompose a system into modules for which each module represent a major step in overall 
process. Object-oriented methodology keeps the real-world objects or decompositions in 
their abstraction and represent them in objects. “Call for Fire” process which is send from 
an observer to FDC for being a fire request, can be represented as an object in O-O. It has 
verbal operations and noun phrases, which describe its behaviors just like the real-world 
objects. It keeps its unity and communicates with other objects. The benefits of objects: 


¢ Similarity of objects to the real-world objects makes disowning of O-O projects easier 
and more readable. 


¢ Dealing with object modules is similar to real-world objects, so, maintains, 
modification and extensibility of the software is easier then conventional ones which 
are created by using top-down structured design. 


¢ For large projects, it 1s easier to decompose the job without losing semantics of sub 
modules. This increases the reliability of subparts. 


5. Code Size and Cost 


One of the tools to estimate the cost of a software 1s Cocomo!. Cocomo 1s a lines- 
of-code-based costing model that estimates the software development cost. The cost 1s 
determined with the formula: 


SM = A * KSLOC? 


In the equation, SM is the number of staff-months which 1s required to complete 
the system development; A is an empirically derived number that converts 1000 lines of 
code into its equivalent cost in SM; KSLOC is the lines of source code (expressed in 
thousands); and B is a factor that compensates for the nonlinear nature of software 


development. [Ref.19: p.363] 


The role of O-O in decreasing the Line of Code (LOC) shows itself with its reuse 


capability. Reusing becomes more effective when: 


1. Barry Boehm’s Constructive Cost Model to estimate effort, man power, and so on [Ref.2]. 
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¢ The size of code (or project) is too large (in ten thousands of LOC) 


« Application completely or partially use high degree of reusable software components, 
like GUI component. 


One point should not be disregarded, reuse, like cache memories, provides 


diverse performances on different problem domains and it mainly depends on design. 
6. Portability 


Portability is mostly dependent on both language and environment. O-O 


paradigm contributes to portability with its encapsulation feature. 


FIGURE 10 on page 42 displays a sample Borland C++ include file which 


#ifdef _ BORLANDC__ 
ye PC-specific includes 
# include .. 


EosliG 


#ifdef Unix 
Hee UNIX-specific includes 
# include .. 


Perches 





Figure 10: Selective includes of a sample Borland C++ header file. 


behaves selectively for include files. Compiler checks the operating system and uses the 
appropriate include files. Since all the modules and objects have two parts which are 
interface and implementation, implementation part could have specific features to its 
environment. The User or programmer is not interested in that part. To port a software to 


another environment requires compiling & linking again. 
7. Project Management 


Designing and implementing systems consisting of tens of thousands, if not millions, 
of lines of code is quite different matter. The effort required to complete such a system 
is Clearly beyond the intellectual physical capacity of one person. [Ref.3: p.7] 
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Gathering more people into a single project creates other problems: 


Communication and coordination. 


FIGURE 11 on page 43 displays the resource allocation for O-O FATDS / FS in 
terms of time. The time which is spent for analysis and design is more than coding. This 
one of the characteristics of O-O. Design decisions effect the future works. Reuse should 


be a project goal like any other [Ref.16: p.44]. 
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Figure 11: Time allocation for development elements. 


a. Project Organization 


There are four types of alternative project development styles [Ref.16: p.44): 
¢ Rapid prototyping 
¢ Round-trip 


¢ The iterative style: Develops a series of solutions to a problem, each one close to 
satisfying the requirements. Each solutions is complete but its accuracy or 
acceptability improves with each pass. 


¢ The incremental style: Builds system functionality a little at a time. It differs from 
iterative development in that the results of each increment are not an entire solution, 
but part of it. This style has been advocated for some time for conventional projects. 
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Object-oriented development is best suited to the iterative or incremental 
style of development. Abstraction of the real world objects in O-O terms makes possible to 
work with objects or modules independently. Object can be put in action as soon as it 
possible whether they are completely ready, or not. This gives a chance for: 


¢ Early evaluation of objects which justifies the rest of the work. 
¢ Estimating the cost of the remaining job more realistically. 
¢ Allocating the resources equally for mid-term goals. 


For is research a model named model-based project development cycle, has 
been applied for FATDS/FS. It is both incremental and iterative. FIGURE 12 on page 44 
shows the object development algorithm with MBPDC. OOD sets the goals of each object. 
Since an object may not be fully functional at moment during the implementation-testing 


process, mid-term expectations should be planned for them (current goal(s)). 


Create new object 


Put the object in the big picture 


modify it or 
increment/iterate its satisfy the current goal(s)? 
implementation 





Figure 12: Object development in MBPDC. 
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Conventional design methodologies have the problem of decomposing the 
problem domain in to functional sub units. Since their modules represent verbal actions, 


conventional languages are not good for iterative development cycle. 
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V. DATABASE MANAGEMENT SYSTEM (DBMS) SELECTION FOR FATDS 


A. INTRODUCTION 
FATDS has a great deal of data to manipulate. Data should be: 


¢ Kept in reliable environment(s) 
¢ Shared from other nodes of the system 


FATDS’s database system should provide: 


¢ A distributed environment: Supporting multiple workstations connected to a local or 
wide-area network, with one or more database servers providing transparent access to 
multiple data sources. 


¢ An advanced user interface: Provided by a graphics workstation or PC with the 
capability of integrating text, graphics, pictures, and possibly sound and video. 


Before implementing the database part of the project two questions should be 


answered: First, what will be the DBMS’s source? It could be: 


¢ Programming language’s own DBMS. 
¢ Application Developers’s own DBMS. 
¢ Commercially available DBMS. 


Second, what will be the database model for DBMS? It could be: 


¢ Object-oriented database model. 
¢ Other database models. 
¢ Composition of database models. 


B. CHOOSING A DBMS SOURCE 
1. Programming language’s own DBMS 


Borland C++ does not have a built-in DBMS like most of the other programming 
languages. If the programming language has provided a DBMS, then: 
¢ It would be completely object-oriented. 


¢ It may be easy to embed DBMS functions or objects into the source code. 


* It may not be satisfactory for the applications requirements, e.g., security, integrity, 
suitability to distributed databases and/or for large objects. 
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¢ There would still be problems about using existing databases (which have been created 
by other DBMSs. 


¢ It would have enforce to use the same language’s native DBMS format for other 
applications. 


2. Application Developers’s own DBMS 


Another option is to develop a DBMS which has been created specially for the 
project or general purpose. It 1s not commercially available. If it is task-oriented then it 
meet all the requirements of the project and acts well with the application code. It does not 
have to be implemented with application’s language, but to embed database system calls 


there should be third party communication programs in application’s language. 


One of the features of this implementation is that it is completely object-oriented 
like the first option. Since this choice under the control of the application developer, it can 


be maintained or modified according to requirements. 


The problem with these kind of DBMSs is maintenance. Its development should 


be included into the project, hence, this increases the project burden. 


3. Commercially available DBMS 


Commercially available DBMSs are also for general purpose, however there is a 
selection option according to the project requirements. These DBMSs are developed 
outside the project (FATDS) environment, so, developing a DBMS never be another task, 
but to use it. It is possible to use/create various databases other than the project’s. If itis a 


widely used commercial DBMS, it will possibly be used longer. 


Disadvantage with this choice is maintance. Only the DBMS vendor can provide 


necessary modifications on the application. 


47 


4. Choosing the DBMS Source for FATDS 


Using a commercially available DBMS is chosen for FATDS. If it does not 
specifically violates the requirements, “buying a product is generally cheaper then 


producing it”. 


One of the advantages of commercial DBMSs is that database can be created 
without using the host application. This provides to use the same database from other type 


of applications locally or via network. 


C. CHOOSING A DATABASE MODEL 
1. Database Model Options 


There are various data models. The major data models are hierarchical, network, 
relational and object data models. Each of the data model is not alternative of the other(s). 


There are advantages, disadvantages and suitable applications for each the data models. 


In hierarchical data model, data is organized in inverted tree structure and is 
accessed form the top the bottom in a series of nodes similar to branches in a tree. The 
inverted tree structure provides clearly defined and fixed path for accessing the data by 
traversing the branches of the tree. The rigidity of the structure has some disadvantages in 
that new access path, not defined at he outset, may complicated or even impossible to 


achieve. Modification of the database structure is a very complex task. 


The network data model traded off some of the high-access performance for 
flexibility in organizing and accessing the data. As in a hierarchical model, the data is 
organized in and inverted tree. The greater flexibility is achieved by allowing a node to be 
connected to more than one branch. Records are linked by predefined pointers. Equal or 


better performance, as compared to the hierarchial model, was achieved by maintaining 
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permanent pointers linking records. The complexity of the data structure made queries 


more complex and modification and ad hoc queries more complicated 


The relational data model promised a structure that met these new requirements. 
Structurally different from inverted trees of the hierarchical and network data models, data 
in the relational data model is stored in tables consisting of columns and rows. Links 
between data records are largely established as needed on an ad hoc basis. The rows of a 
table represent records and the columns within a table represent the fields in a record. 
Different types of records are stored in separate tables. Some frequently used connections 
between tables can predefined, while others can be established at the time of query. The 
data and their description are maintained separately, but changing data description is not 
simple. This model achieved the desired flexibility and ease of use, but at a cost. The 
relational data model requires a higher level of processing to establish connections and 
access data. Consequently, system requirements for processor and memory are higher to 


achieve the same level of overall performance. 


The Object data model differs itself from other models representing real-world 
data in intelligent objects which combines the abstraction and behavior of the real-world 
objects. Direct correspondence between real-world and database objects maintains 
integrity and identity of objects so they can be easily identified and operated upon [Ref.13: 
p.442]. Objects have their own behaviors, this provides them to interact with other data 


models. Advantages of the object data model: [Ref.13: p.444] 


¢ Extensibility: Object types and their methods can be modified as needed. Such changes 
are localized to the relevant object type and hence are much easier than in record- 
based system. 


¢ Behavioral constraints: Because of encapsulation, the behavior of each object type is 
predetermined by a fixed set of methods. Hence, database operations are constrained 
to be within these behavioral specifications. 


¢ Flexibility of type definition: The user is not limited to the modeling concepts of data 
model but can define many variations of data types, each with unique properties. 
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¢ Modeling power: The inheritance of both attributes and methods is very powerful tool 
for data modeling. In general, the abstractions of generalizations/specialization, 
identification, and aggregation are well supported in the current data models. 


Disadvantages of the object data model: 


¢ Lack of associations: The abstraction of association is not directly supported and is 
achieved indirectly by allowing interobject references. This is an inherent weakness of 
the O-O approach. 


¢ Behavioral rigidity: The predetermining and prespecifying all operations by a fixed set 
of method create this rigidity. 


¢ No high-level query language: There are no high-level query languages for current 
data models. 


2. Interfacing Objects with the Other Models 


Object-oriented databases provides to write and read objects to the disk, normally 
using static or dynamic link libraries with the code. The physical storage format on the disk 
is hidden from the application. The format can be flat files, relational files, hierarchical 


files, or any other type. 


The most primitive OODBMSs use a custom file format and enable you to only store 
objects on disk. These products offer little advantage.... Likewise. the manufacturers 
of these products require you to purchase their software and, occasionally, a run-time 
license for each product distributed. [Ref.20: p.5] 


A OODBM may either: 


¢ Store its objects using a format compatible with existing commercial database 
management systems such as Oracle, Sybase, dBase IV, or Paradox: Data consistency 
1s ensured and all transactions are performed internally by the OODB. The 
disadvantages are technical difficulties and the relatively slow performance. 


¢ Exists in parallel with a commercial database management system that mirrors the data 
in the object-oriented database: It requires an update scheme to ensure that the data in 
both databases remains in synch. Accessing data in an object-oriented database is 
much faster -2 to 10 times faster- than in an relational database. 


3. Choosing a Data Model for FATDS 


There is no single data model which completely fits FATDS’s database 


requirements. Object-oriented databases can interface with other data model. This provides 
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the opportunity of combining the advantages of different data models. For this research, 


interfacing objects with relational DBMS is selected. 


In relational DBMSs, the structured organization of data in tables and the 
capability of the database system to interpret each column of data serves well for 
applications involving pure numerical and textual data. Variable length data elements such 
as free-form text, images, and voice does not fit into the structure of relational databases. 
Relational database vendors created a new class of data type called Binary Large Objects 
(BLOBs). These data types can hold very large (and variable length) data and they are not 
interpreted by the database. This new feature provides relational DBMSs to support 


multimedia data management. 


Relational database model has advantages that the OODBM can not support: 
eete22.)p.08|{Ref.26: p.33] 


¢ The relational schema is stored in the database catalog. 
¢ General-purpose query programs can use the catalog. 


¢ The SELECT, PROJECT, and JOIN operators can build new database views at run 
time. 


¢ The database is cross-compatible with other applications that use the same DBMS. 
¢ The data and their description are maintained separately. 


The object data model has advantages that the relational data model can not 


support [Ref.22: p.68][Ref.18: p.169]: 


¢ Variable length data member: /t can support such applications as imaginary, 
multimedia, geographic data, weather. 


¢ Abstraction: The behavior of an object is described by a class definition that ts created 
by data abstraction. By incorporating data abstractions at the level of the database, it 
is possible to make changes to the way a database class is implemented. 


¢ Class extensibility: Jn a relational database, the only parameterizable type is a 
relation, and the only operations possible on all relations are get_field_value and 
set_field_value. In the object data model, interface of each object is customized to that 
object. 


¢ Arrays permit repeating groups. 
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¢ Encapsulation: Encapsulation of data formats with methods bind data representation 
and behavior. 


Polymorphism: Customizes the behavior of derived data types. 


Integrity: Especially for large systems, the integrity of analysis, design and 
programming to map the real-world data into objects provides the simplicity to build 
the database system. This provides easy maintenance of the database system. 


Reusability and adaptability: They are the two important features of object-oriented 
systems, which are accomplished using inheritance. 


OODBMSs are faster: Because, relational databases pull information from a variety of 
tables into one result set, based on JOIN operation while OODBMSs make the same job 
by calling member functions. 


Automatic type checking at the point of use: The object-oriented database performs 
type checking on the arguments to method calls. Thus, type errors are detected at the 
time of invocation rather than at the end of a transaction. 


Schema evolution: Conventional data models do not support efficient mechanisms for 
schema evoluton. Object data model allows user-defined operations making the 
addition easier. Schema evolution includes changes to the defination inside a class and 
changes to the structure of the class lattice. A set of invariants and rules can be defined 
so that the schema will remain consistent as it evolves. 


e 


e 


@ 


@ 
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D. DBMS FOR FATDS 


FATDS’s database is implemented in object-oriented fashion which interfaces a 
commercial DBMS, Paradox. Borland’s Paradox for Windows, version 1.0, is a relational 
DBMS. Paradox provides network support, password protection using encryption, binary 


large objects (BLOBs), multiple indexes, and composite indexes. 


To use Paradox table in the applications and embed into the C++ source code a third 
party Engine is need: Paradox Engine. The Paradox Engine, version 3.0, is and API 
containing more than 90 functions accessible from a C, C++, or Pascal program. The 
Engine provides to create database tables and indexes and to perform all database-related 
operations. The Paradox Engine is implemented as a DLL (for windows) that can be 
distributed royalty-free. The problem with the Engine is the DLL file is implemented in C, 


So it is not object-oriented. To keep the applications completely implemented in O-O, 


nye 


another DLL file is created, which is in O-O. The design and implementation issues of 


FATDS’s database is discussed in the next chapter. 
The benefits or advantages of this choice: 


¢ Working with other data format files too: The application(s) may have to work with 
other data formats. FIGURE 13 on page 53 displays the object-interfaced data 


Application, 


Database object(s) 


Oe 


Paradox 
database 


" Any DBMS, other then Paradox 





Figure 13: Object-interfaced data environment 


environment. Objects can be implemented to filter diverse database formats, hiding 
unnecessary details from the users and end-programmers. Only the database object are 
necessary to be updated according to the target database, not the application. This 
makes the modification easier. 


¢ Using a reliable DBMS: Instead of creating a DBMS which is normally a independent 
task, using a commercially developed (so testedO provides more reliable DBMS 
environment. 


¢ Faster database development: Data does not have be created or maintained by the 
mission-oriented applications. It should be created/maintained without running the 
application or creating a special program. Database design and implementation of 
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FATDS, including custom forms, can be created by Paradox for Windows, without 
using any user-created application. 


¢ Using the data with other applications: Other applications created independent from 
FATDS may use the same data. Regarding the hugeness of the project and time period 
of using the application, generally accepted data formats provides flexibility in use. 
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VI. OBJECT-ORIENTED DATABASE DESIGN OF FATDS 


A. INTRODUCTION 


The database system of FATDS is determined as object-oriented database system 
which incorporates a relational DBMS. OODBMS has a front-end role in this system and 
back-end could be any DBMS in any data model. Object structure of the system facilitates 
to work with heterogenous back-ends. Using various DBMSs as a back-end effects the 
design of the database. Back-end database could be: 

¢ Created independent from the front-end implementation. 
¢ Created simultaneously or incorporating with the front-end. 

Two of the situations may effect the object design differently. Creating the object- 
database as a front-end together with the back-end database may increase the reusability of 
the objects for later developments. For this research first option is followed to show: 

¢ How object-oriented database systems coexists with the existing databases. 
¢ The benefits of object-oriented database system interfacing with relational DBMSs. 

One of the benefits of the of OODBMSs is their implementation language. Non-O-O 
database system mostly have their own data languages which are not capable of complete 
computational power like programming languages. OODBMSs’ languages are complete 
programming languages as well. This facilitates to combine database development and 


program development together. 


Design methodology will follow the steps: 


¢ Identify the basis for the database requirements 

¢ Define the database’s functional and performance requirements 
¢ Conceptual design 

¢ Identify classes 

¢ Identify attributes and services (member functions) 

¢ Identify the relationship between classes 

¢ Database implementation 
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B. DATABASE REQUIREMENTS AND ANALYSIS OF FATDS 
1. The Role of Artillery 


The mission of field artillery (FA) is to destroy, neutralize, or suppress the enemy 
by cannon, rocket and missile fires and to assist in integrating fire support into combined 
arms operations. The main role of FA is to ease the achievement of commander’s objective 


with its fire power. The commander is a maneuver unit commander at any level. 


Targets could be anything on the battlefield: Enemy units, bridges, areas, roads, 
tanks, trenches, convoys, etc. Main point is that targets are not artillery’s, but the 
commander’s. So, all the target acquisition elements work under the maneuver 


commanders’ control. 


Since artillery normally does not have eye contact with the enemy targets, he 
relies on different sources for the target information; forward observers, air observers, 
radars, electronic counter measure units, higher headquarters, reconnaissance/intelligence 
units, commander himself, etc., almost everybody on the battlefield is source for target 


acquisition. A target could be immediate one or planned before. 


Depending on the organization of the FA there could be diverse weapons systems. 
Each weapon system has its own munitions and firing tables: Firing table is a book which 


displays all numeric data about a specific gun & munition(s) combination. 


Although there are many, only the following major application functions are 


taken into account for database implementation: 


¢ Target management 
¢ Gun management 
¢ Firing table management (Table-F only) 


Other database areas are: 
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¢ Corrections management: [t keeps and manipulates firing corrections for each gun and 
position pairs. 


¢ Fired mission history management: /t is a derived database management. 


¢ Known points management: Radars, observation post positions, etc., are all known 
points. 


¢ Ammunition management: Amounts, type, caliber, lot are the fields to be managed. (It 
is designed but not implemented.) 


¢ Met messages management: /t keeps up-to-date met messages. 


¢ Friendly forces management: Positions of friendly forces and other regions which are 
necessary for fire coordination, planning and security. 


2. Application Functional Requirements Overview 


a. Target Management 
Each target is assigned a number like “AB2124”’, First three digits represent 
a specific unit or element while the rest represent consecutively target numbers which are 
assigned to that unit/element. All the targets should be located at least with its coordinates, 
height and description. In addition to those: source (who located), locating accuracy, 
located time, category (there are 13 category groups and each target fits at least one of 


them), fired/notFired, priority, restrictions. 


Targets could be a point, a region (with a size), target groups (two or more 
targets with a different identification name), target series (more than one targets and/or 
target groups with a special name). Battalion FDC can form a target groups and series. A 
sample group name is B1C; letters represents who forms that group, the number digit in the 
middle is consecutive group number. A sample name for series of targets is CASEY, just a 


nick name. 


The decisions that comrise the decide function include: 


¢ What targets should be acquired and attacked. 

¢ Where and when the targets will likely be found and who can locate them. 
¢ How the targets should be attacked. 

¢ Whether target damage assesment is required. 


FDCs will be able to keep track of unlimited number of targets. 
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b. Gun management 
Each gun has a unique number within a battery. Together with battalion name 
and battery name each gun has a unique name. Guns can be organized in some batteries as 
platoons (four guns in a platoon and two platoon in a battery), if not, a battery has six guns. 
All the guns in battery are identical to each other. One of the guns in the battery is assigned 


as the main gun. 


In addition to name and each gun has position coordinates, model, maximum 
range, maximum left/right deflection, common orientation deflection, orientation 


deflection, firing table name. 


c. Firing Table Management 


Each gun has its own firing table. A firing table 1s composed of various tables: 


¢ Table-A: Line numbers of meteorological message. 

¢ Table-B: Complementary rang line number. 

¢ Table-C: Wind components. 

¢ Table-D: Temperature and density corrections. 

¢ Table-E: Propellant temperature. 

¢ Table-F: Basic data and correction factors. 

¢ Table-G: Supplementary data. 

¢ Table-H: Rotation-range. 

¢ Table-I: Rotation-azimuth. - 
¢ Table-J: Fuze correction factors. 


Above tables are for specific shell type/model, fuze type/model and 


propelling charge/type. 


All the firing table data are constant. Any application should not be allowed 


to modify the tables. 
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C. DATABASE DESIGN OF FATDS 
I. Conceptual Design 


FIGURE 14 on page 60 and FIGURE 15 on page 61 display the ER diagrams for 
the Target, Gun and Table-F entities. The conceptual design is performed according to 


relational data model concepts. 


2. Identify Classes, Attributes and Services 
The classes which are formed as the front-end database classes are: 


¢ DBGunCls: Gun database management class. 
¢ DBTargetCls: Target database management class. 
¢ DBTable_F_Cls: Table-F management class. 


Tables 3, 4, 5 displays the data members and data functions of the database 


classes: 


TABLE 3: DATA MEMBERS WHICH ARE USED BY ALL THE DATABASE CLASSES. 


Ret Ce numb cacti ae ied simincidalabacataciomen number of the fields in the database table. 
| Holds the names of the all the table field names. the names of the all the table field names. 


Holds the type codes for en field of the database 
table. 
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Figure 14: ER diagram for FATDS/FS schema (gun, target, munition) 
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Figure 15: ER diagram for FATDS/FS schema (Table F) 
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TABLE 4: MEMBER FUNCTION WHICH ARE USED BY ALL OF THE DATABASE CLASSES. 


RecordTobuffer | Protected Takes the field values from the database table from § 
where the pointer is, and puts it to the buffer fields. 
ReadFirce Public Moves the database pointer to first record and 
reads the record into the record buffer. 
ReadLast Public Moves the database pointer to last record and 
reads the record into the record buffer. 
ReadNext Public Moves the database pointer to next record and 
reads the record into the record buffer. 


ReadPrev Public Moves the database pointer to previous record and 
reads the record into the record buffer. 















isTableEmpty Public Checks the table if it exist or empty and return 
TRUE if it is empty. 

Teves Sie Public Checks the if the pointer is at the last record and 
returns TRUE if it is the last record. 

Reset Public Empties the record buffer and sets all the attributes 
to initial states. 
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TABLE 5: MEMBER FUNCTION WHICH ARE MOSTLY USED BY SOME OF THE DATABASE 
Buff MeitertoRecord | Protected | Takes the | Takes the values from the buffer and puts them to _ from the buffer and puts them to 
the database table to where the pointer is. 
primary key that requires the database to be kept in 
meneteRecord Deletes the current record. 
Retrieves a Retrieves a field value from the buffer area. value from the buffer area. 


CLASSES. 

AddRecord Public Adds the record buffer to the database. (The record 
is appended if the database does not have a 
sorted order.) 

UpdateRecord Public Copies the record buffer into the database as an 
update of the current record. 

SearchByKey Searches the key field for a given field value. 

Set the a field value into the buffer area. 

Any other ee 

member function(s 

3. Database Implementation 






a. Paradox Database Tables Organization 


Table 6 displays the valid field types used in Paradox tables. 


cd 
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TABLE 6: PARADOX FIELD TYPES 


Storage Size 


n+10, where is 
in the range of 0 
to 240 


Description 


Floating ’ Floating point number with 15 significant digits inthe _| number with 15 significant digits in the 
fange of 10° tom10 -«. 


Integer in the range of -32,767 to 32,767. 


Same as floating point, but fixed at two digits of the 
decimal. 


NULL-terminated string of length nnn, where nnn is 
less than 255. 


Unformated text BLOB. n represents BLOB-related 
header information, and the actual data is stored ina 
separate file pointed to by the file name stored in 


Paradox. 


Same as the preceding, but for unformated binary 
information. 


n+10, where is 
in the range of 0 
to 240 


n+10, where is | Same as the preceding, but for formated text. 
in the range of 0 


to 240 


n+10, where is | Same as the preceding, nut for Windows OLE objects. 
inthe range of 0 


to 240 


n+10, whereis | Same as the preceding, but for graphics data. 
in the range of 0 


to 240 





b. Database File Organization 
The Paradox Engine provides the pxengwin.dll DLL file together with 
pxengine.h header file. Engine is implemented with C language, thus it 1s not object- 
oriented. The Engine with its more than 90 functions provides all the database file 


manipulations including: 


¢ Create, read, and write Paradox tables, record, and fields in DOS, Windows, and 
network environments. 


¢ Create, read, and write Paradox BLOB fields. 


¢ Support explicit interactive Paradox and Paradox Applications Language (PAL) 
applications, as well as other Paradox Engine Applications. 


¢ Support other Paradox features such as password protection, encrypted table, date 
encoding, searching, and error handling. 


¢ Import data into Paradox tables through serial communications, such as when 
downloading form mainframes or from external devices that can not be reached from 
PAL. 


¢ Create stand-alone applications or applications that can be run with the PAL RUN 
command. 


FIGURE 16 on page 66 displays the file organization for the database 
development of FATDS. In order to create an object-oriented database engine, another 


DLL file is created namely paradox.dll. Paradox.dll is created with the files: 


¢ Paradox.*: Loads other header files required for others, support proper memory 
allocation if multiple applications are simultaneously using the paradox.dll. 


¢ Pdoxeng.*: /nitialize the engine and shuts it down. 


¢ Pdoxrec.*: Performs single record operations in a database table such as putting data 
into the field or get data from the field. 


¢ Pdoxtab.*: Jt the engine is initialized it attempts to open a specific database table. If 
there is not that table, then it creates new one. 


Paradox.dll uses the Paradox Engine only. Database classes work with 
Paradox.dll. This hides all the Paradox implementations into the database objects. 
Application(s) is just aware of an object-oriented database implementation as a front-end. 


The database objects may interface any DBMS. 
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dbgun.cpp dbgun.h 
dbtarget.cpp dbtarget.h 
dbtbl_f.cpp dbtbi_f.h 





Figure 16: Database development file organization 


VII. CONCLUSION AND FUTURE WORKS ON FATDS 


A. SUMMARY AND CONCLUSIONS 


This thesis concentrated on the benefits of object-oriented approach over FATDS on 
sample programming implementations. The object-orientated approach mainly 
distinguishes itself form the other conventional ones especially in two phases: Design and 
maintenance. Object-oriented approach offers increased modeling power to represent the 
real world in a problem domain, a high level of abstraction, and the ability to inherit and 
refine object properties. Design takes the greatest portion of the software development 
cycle. Maintenance 1s not just an after-development-event, but a continuing phase with the 


design during the software’s life-time as well. 


The object-oriented development of FATDS is accomplished using a methodology 
namely model-based project development cycle. This methodology depends on the fact that 
nothing is perfect and a question that is “is this what you want?’. A development of a 
project should begin somehow, with a model of the product. The model is a prototype-like 
working element which gives an idea about the product but not necessarily a completely 
functional one. This model provides a chance to evaluation about the product and justifies 
the rest of the work. Evaluation causes modifications on the project. The inheritance, 
polymorphism and object abstraction features of object-oriented approaches facilitates the 
modification of the software and provides faster project development which satisfies the 


requirements than the conventional paradigms. 


By promoting code reusability the object-oriented paradigm reduces the cost and time 
required for software development. In order to exploit the reuse and portability of power of 
O-O approach, design plays the key role. Object-oriented approach does not differentiate 
itself from other approaches without a good design. Thus, project members need to be 


experienced on OOA and OOD. 
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FATDS has the following features which make to work with object-oriented approach 
more beneficial than of the conventional ones: 


¢ Large-scale systems. 


¢ Modification on the software is frequently needed with new concepts, weapons, 
communication systems etc. 


¢ FATDS operators are short-termed trained on that system(s). 
¢ Incorporates a diverse large and distributed database. 
At the beginning of a object-oriented software development, the power of reuse may 


not put itself strong since there may not be much objects which are created before. As the 


development goes on, the speed of project development increases logarithmically. 


Advantages of object-oriented databases are that it offers the designer a high level of 


flexibility and power to implement arbitrarily complex and operations. 


Object-oriented database structures should resemble C++ or some other object- 
oriented language program structures for data in memory (that is, the equivalent of class 
instances or objects), thereby minimizing discontinues between programming and database 
operations and structures. A good OODBMS must be a full object-oriented database system 
that is designed to support large-scale object databases. It should reflect the object 
paradigm with object encapsulation and inheritance of both data and functions.[Ref.1: 


p.169] 


B. FUTURE WORK 


The programs, both the OChart and OFire are not completed and well-tested for 
complete functionality, so 1s the database of them. The followings will be done on the 
programs: 

¢ Firing with special munitions 
¢ Firing with met + MV. 


¢ Interfacing with outer devices. 
¢ Creating the other parts of the firing table databases and for other guns as well. 
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To continue on programming development increases the objects which are created, so 
does the reusability. This gives more reliable bases to compare object-oriented paradigm 


with the others. 
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APPENDIX A. (OFTIRE HEADER FILES LISTINGS) 


Listing A.1: BURSTS.H header file 


[ [RRR RRR EERE EK REAR RREA EERE RRR ee 


oe 

// bums sem 

yy 

// header file for the classes BurstsWndCls 
SH SheafWndcls 


[ [RRR RRR RE ERERERAERARR KR RERK A KKK RAH RK eee 


#ifndef BURRS S2r 
a define _ BURSTS_H 


//note that the following code is executed only 
//if this file has not been previously included 


include “fires. 


#define ID_CONVERGED 101 
#define ID_PARALLEL 102 
#define ID_SPECIAL 103 
#define ID_OPEN 104 
#define ID_GUNS LOS 


_CLASSDEF (SheafwndcCls) 
_CLASSDEF (BurstsWwndcls) 


J /mrmrmetant nts te a eae SSS SSS a ESS SS SS Sa a a es a a a ee eee 
// class BurstsWndcls 
he 
// Purpose : Displays the bursts on a canvas for’ each gun and allows 
es the user to modify them. 
fi: 
// Notes 
// 
// Copyright: Copyright. (ec) 1992s iWwistatawnoak 
rae All Rights Reserved 
ee 
class BurstsWndCls : public TWindow 
{ 
private: 
RECT WndRect; 


PSheafWndCls SheafWnd; 

PButton2Cls ButtonConverged; 
PButton2Cls ButtonParallel; 
PButton2Cls “BuretonSpecial:> 
PButton2Cls ButtonOpen; 

HBITMAP hBitmapl; //north sign 
HBITMAP hBmpLeftArrow; 
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milblic: 


( 


PTList Box 


ListGuns; 


BurstsWndCls(PTWindowsObject AParent, 


LPSTR 
sl on ee ae 


ATitle, 


Ligh, Seep Ligtiog eo .@ 


~BurstsWndCls(); 


warctual 
virtual 
virtual 
virtual 
virtual 
virtual 
virtual 
woartual 


virtual 
Virtual 
virtual 
virtual 


Notes 


Bepyright: Copyright 


private: 


RECT 


ery te 


Old 
void 
vo1d 
void 
void 
vo1d 
woud 
wold 


void 
Vola 
vod 
void 


SetupWindow() ; 
Paint (HDC PaintDC, 
ConvergedSheaf (RTMessage) 
ParallelSheaf (RTMessage) 
SpecialSheaf (RTMessage) 
OpenSheaf (RTMessage) 
Guns (RTMessage) 
Dreaweboraer (HDC HDC, int x 
BOOL isUp); 
UpdateList (); 
UpdateButtonArrow() ; 
UpdateInfoArea() ; 
UpdateSheafWindow(); 


ol er tl 


SheafWndcls 


bisghemmels Gy len 


Par StRuCLS) 


Pep PE TR GT 
LEDestRSsT 
Pipe FIRST 
(I pePiIRST 
(IDUFIRST + 
pegs Ze 


+++ + 


Ineax 2 


ID_CONVERGED}; 
ID PARALLEL] ; 
ID_SPECIAL]; 
TP OPEN); 
ID_GUNS]; 

eee Ver 


emcee mec wc ww ec wc ew wae i 
meee eee ccc ccm cmc ccm mmc cr ae ee SS 


Creates a canvas for BurstsWndCls as a child window, 
displays the bursts. 


rors eel Go 12 ee 


All Rights Reserved 


public TWindow 


WndRect ; 
Peer SsOR hCursorTo; 


pees 
Cy; 


ScaleFactor; 


SheafWndCls(PTWindowsObject AParent, 


LPSTR 
igh ere: 


ATitle, 


Tinea eet CN, 


~SheafWndcls(); 


martial 
waertual 
earrtual 
warcual 
wartual 


Mustafa ESER 


vite mely }:* 


i rr cc rc el 
meee ae a 


class SheafWndCls 


LPSTR GetClassName(); 

vold SetupWindow(); 

void Paint(HDC PaintDC, PAINTSTRUCTS&) ; 

void WMLButtonDown(TMessage &Msg)=[WM_FIRST +WM_LBUTTONDOWN] ; 
void WMSetCursor(TMessage &) ={WM_FIRST + WM_SETCURSOR] ; 
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#endit Le BURSTSen 


Listing A.2: BUTTON2.H header file 


[ [RRR RRR ERE ERR REE K KICK EK KE eee 


fy 

hg bubten ein 
// 

// header file for Button2Cls class 


[ [BEER REE RERKRRRER ERE EERE KR RR EK Nee ee a ee 


#ifndef —_ BUTTONZ 2h 
# define __BUTTON2_H 


//note that the following code 1s executed only 
//if this file has not been previously included 


#ifdef — BORLANDC__ 
// PC-specific includes 


# include =cewls a 
# include 2=buGcten nh 
#endif 


#ifdef Unix 
or UNIX-specific includes 
#endif 


_CLASSDEF (Button2Cls) 


ee 
// class Bub tenZeils 

ia : 

// Purpose : Creates a custom button. It inherits all the behavior 
ie TButton class and adds the following features: 

fy >It has a constant background. 

Bef: >It may be instantiated with atmost two bitmap 

eA resource name. if it 1s intanctiated with two 

a bitmaps, it displays the first one regularly and 
7 displays the second one when the button clicked. 
// If it is instantiated with one bitmap only, then 
he it displays that bitmap for all occassions. 

fig It may be instantiated with no bitmaps. 

Ved. >Bitmap is displayed on the right of button while 
jek the text. Geconmetheomlcimier 

Hae 

// Notes : The size of bitmap file should be smaller than the 

fs button sizes. Otherwise the bitmap is clipped. 

// Copyright: Copyright (c) 1993, Mustafa ESSER 

Ve All Rights Reserved 


tive 


miss Button2Cls : public TButton 
{ 


private: 


Smarr Text [80]; 
Reet BRect; 
HBITMAP hBitmapl; 
HBITMAP hBitmap2; 


protected: 


Virtual void ODADrawEntire(DRAWITEMSTRUCT _FAR & DrawInfo); 
Virtual void ODAFocus (DRAWITEMSTRUCT _FAR & DrawlInfo); 
virtual void ODASelect (DRAWITEMSTRUCT _FAR & DrawInfo); 
virtual void DrawFrame(HDC hDC, RECT Rect, BOOL Selected); 
[merial void WriteText (HDC hDC, LPSTR Text); 

wit wal void PutBitmap(HDC hDC, BOOL Pressed = FALSE); 


miiolic: 
Button2Cls (PTWindowsObject AParent, 

ogc reegkol 
LPSTR AText, 
LPSTR BitmaplName, 
LPSTR Bitmap2Name, 
ie Re 
Tite ee 
int W, 
ob gte H, 
BOOL IsDefault, 
PTModule AModule = NULL); 


Peuetonz2cls(); 
a? 


femert BUTTON2_H 





Listing A.3: COMMAND.H header file : 

ec KKK KEKE RR LEER ERR ER KKKKKKKKEKKEKKKKEKEE EEE EEK EEKEKEKKE 
ol 

i command.h 

v7 

J// Meader file for CommandwWndCls, 

// FireCommandswWndCcls, 

vf Infowndcls, 

7 / SubFireCallWndcls, and 

ia ChronowndCls classes 


ne A KAA AK KAKA AKEAEAAKAKAEAEKEKEKKEAKKKAEKEKKEKEEAKEEKKKEKKKKEKKKEKKKKEKS 


#ifndef __COMMAND_H 
5 define _— COMMAND H 


//note that the following code is executed only 
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//if this file has not been previously included 


Hine lidew”" tire. 


#define MAXVLINE 6 
#define MAXHLINE 8 
#define ID SEND 100 
#define ID_FIRE Ieee 
#define ID_INFO 20 1) 


#define ID_FIRECOMMANDS 301 
#define ID_SUBFIRECALL 401 


#define ID_CHRONO Soul 
#define ID _WHENREADY 502 
#define ID_ATMYCOMMAND 503 
#define ID _ATTIME S04 
#define ID _AFTERTIME S05 


_CLASSDEF (CommandwndCls) 
_CLASSDEF (FireCommandswWndCls) 
_CLASSDEF (InfoWndCls) 
_CLASSDEF (SubFireCallWndcls) 
_CLASSDEF (ChronoWndCls) 


//saarBErtSetSrtsssst Sess SSt St tt St StH StS TST TST SESS SS SSS ST SHS SET SESE SETS S==== 
// class CommandWndCls 
ii 
// Purpose : Hosts the other child windows. 
ae 
// Notes : It has one more constructure which is encapsulated as 
// protected. It 1s suppossed to be used only by its sub 
fo classes. 
ig 
// Copyright. Copyrigna (2) loose Musrartce roe 
as All Rights Reserved 
ee 
class CommandWndCls : public TWindow P 
{ 
private: 

RECT WndRect ; 

PFireCommandsWndCls FireCommandswWnd; 

PInfowndCls Tnrownd- 

PSubFireCallWndCls SubFireCallwnd; 

PChronoWndCls Chronownd; 

PButton2Cls But cenSend- 

PButton2Cls ButtonFire; 

PButton2Cls ButtonFireCommands; 

PButton2Cls BUeEEOCRINES: 

PButton2Cls ButtonSubFireCall; 

PBUEGCNZEels Bue eoncCmcne. 
pubiie: 


CommandwWndCls(PTWindowsObject AParent, 
LPS'TR ATitle, 
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ate ae 


TGNE Y, 
sae ax 
int ya 


~CommandawndCls(); 
virtual void SetupWindow() ; 
fePeual void Paint (HDC PaintDC, PAINTSTRUCTS); 


virtual void Send(RTMessage) =r tRolot LD SEND); 
virtual void Fire(RTMessage) =SalelOee Tee) + [D FERRI: 
virtual void FireCommands(RTMessage) = [ID_FIRST + ID_FIRECOMMANDS] ; 
virtual void Info(RTMessage) Sibert iRneoress [1D INFO]; 
virtual void SubFireCall(RTMessage) = {ID_FIRST + ID_SUBFIRECALL] ; 
Peeeieal yoid ActivateChronometer(long aT); 

procected: 
CommandWndCls (PTWindowsObject AParent, 

LPSTR ATitle); 

a; 

SB SSS SSS SS 2525S 25====— =]. 2. =. SS Se = 

// class FireCommandsWndcls 

Af 

// Purpose : Display fire commands for each gun which is to fire. 

ri 

// Notes 

a) 

Mempeopyrighnt: Copyright (c) 1993, Mustafa ESER 

i/ All Rights Reserved 

/ / eee ae eee ee ee ee ee eee eee St ===== 

class FireCommandsWndCls : public TWindow 

{ 

private: 


RECT WndRect; 
int VLine [MAXVLINE-1];//x coordinates of vertical lines/borders 
int HLine [MAXHLINE+1];//y coordiantes of horizantal lines/borders 


malic: ’ 
FireCommandsWndCls (PTWindowsObject AParent, 
LPSTR ; ATitle, 
ae x 
int ber 
Tee ax. 
wigs ele). 


~FireCommandsWndCls(); 
virtual void SetupWindow(); 
virtual void Paint(HDC PaintDC, PAINTSTRUCTS) ; 


eee 
// class InfoWndcCls 

Ef 

Mmeerurpose =: Displays fire call, fire order and message to observer 
rf messages after they have been set. 


iD 


fy 


// Notes 
Ie 
// Copyright: Copyraght (ec) 19937 iiiseacaee oer. 
Hep All Rights Reserved 
| i 
class InfoWndCls : public TWindow 
{ 
private: 
REG WndRect; 
public: 


InfoWndCls(PTWindowsObject AParent, 
LPSTR ATitle, 
int xk ine y. Int dxeeneecia 
~InfowndCls(); 
virtual void SetupWindow(); 
virtual void Paint (HDC PaintDe, PAINTSTRUe rT. }-- 


// class SubFireCallWndcls 
// Purpose : Displays subsequent fire calls. 
// Notes 


// Copyright: Copyright “(c) 91993) tieeataweerk 
yore All Rights Reserved 


class SubFireCallWndCls : public TWindow 
{ 


private: 
REG WndRect; 
public: 


SubFireCallWndCls (PTWindowsObject AParent, 
LPSTR ATitle, 
int Xin inte.) “need: 
~SubFireCallwndcls(); 
virtual void SetupWindow(); 
virtual void Paint (HDC PaintDC, PAINTSTRUCTS&) ; 


ye a 
// class ChronoWndCls 

as 

// Purpose : Displays a digital chronometer fom sctings tiem te une 

// time. It also instantiates the firing if 16 vs a ewes 
yey. aly ate 

ES 

// Notes : Windows 3.1 allows only 16 clocks to work simultaneously, 
Va each OFIRE program executes one already. 
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tes 


Mempeeoyright: Copyright (c) 1993, Mustafa 


All Rights Reserved 
class ChronoWndCls public TWindow 


{ 


private: 


PTBRadioButton 
PTBRadioButton 
PTBRadioButton 
PTBRadioButton 
Rec T 

WORD 

WORD 

long 

ig ee 

9ne 

Biba) 


RadioWhenReady ; 
RadioAtMyCommand; 
RadioAtTime; 
RadioAfterTime; 
WndRect; 
wTimer; 
wElapse; 

dTime; 

Hours 

Minute- 

Second; 


Public: 


ChronoWndCls (PTWindowsObject AParent, 
Pee ATitle, 
petits De 
ai © Me, 
singe ax, 
note te dy); 

mel OnOowndaC ls {) ; 

virtual void SetupWindow(); 

wieeuwal void Paint(HDC PaintDC, 

virtual void WMTimer (RTMessage) 
virtual void WhenReady (RTMessage) 
virtual void AtMyCommand (RTMessage) 
virtual void AtTime(RTMessage) 
virtual void AfterTime(RTMessage) 

Pmeeial void StartCountDown(long dT); 


#endif _ COMMAND_H 


Listing A.4: FIRE.H header file 


PAINTSTRUCTS&) ; 


(WM_FIRST 
ler RS © 
(ear ke SA. 
(PROM r alr ST: 
baer ER Sa, 


+++ 4 4+ 


WM_TIMER] ; 
ID_WHENREADY ] ; 
ID_ATMYCOMMAND] ; 
PD SAT DME; 
ID_AFTERTIME] ; 





[ [RRR RK KKK RK KR KK KR KR RRR KR KK RK RK KR KR ee ee ee eee ee ee eee ee 


// 

i / fire.h 
// 

// neader file for dialog class declerations which are: 
// FireCallDlgCls, 

1a PolarWndCls, 

fof ShiftWndcls, 

ye] Gridwndcls, 

// SuppressionwndCls, 

V7 FireOrderDlgCls, 

// MTODI1gCls, 

iif SubrairecallDlgcCls, 


1 


ae TOTAtTimeblagels., 
es TOTATterTimeDil gels. 


[ [BERR RHR HHH RAR AAR EERE REAR AH EK KAR ee 


#ifndef ~ PIRES 
# define __FIRE__H 


#ifdef _ BORLANDC__ 
PC-specific includes 


include 
include 
include 
include 
include 
include 
include 
include 
inelude 
include 
include 


<owl .h> 
<edit .h> 
<listboxan 
<combobox.h> 
<SCrol iba. n= 
<dlialogeun— 
<bpwee .h> 
=<bDuttonen- 
<String o- 
<bchkbox.h> 
<pradice.n= 


endif 


#ifdef Unix 
ja, UNIX-specific includes 
#endif 


#inc ludew’ Sut Genz. mae 
#includes"dbeardec. a]. 
#includew7dequinen. 


//firecall dialog 


#define ID _FIREORDER 106 
#define ID_VIEW O05 ‘ 
#define ID FROM OF 
#define ID_MISSIONTYPE 108 
#define ID_SIZE 109 
#define ID_POLAR dE 
#define ID _SHIFT ar 
#define ID_GRID a2 
#define ID SUPPRESSION als 
#define ID_DESCRIPTION 129 
#define ID_TARGETNO bE 
#define ID_DIRECTION Heel 
#define ID_DISTANCE 102 
#define ID _UPDOWN 103 
#define ID SHIFTFROM OA 
#define ID _RIGHTLEFT pS) 
#define ID_ADDDROP 106 
#define ID_ZONE 107 
#define ID_EAST 108 
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Ot 


#define ID NORTH 


#define ID_HEIGHT dele 
//mto dialog 

#define ID_MTO 101 
#define ID PROCESS 110 
Poerine ID UNITTOFIRE 107 
#define ID_GUNLIST hiss 
#define ID_ADJUSTINGELEMENT 108 


//sub-fire call dialog 
#define ID_DEVIATION 
#define ID_DISTANCE 
#define ID_HOB 


#define 
foaefine 
@acrtine 


Pe SHOUR 
ID_MINUTE 
[D_SECOND 


// class 
(ay 

// Purpose 
| 

// Notes 
Lf fies var 
ff 
feemeooyright: 


Demonstr 


It work with Paradox Engine, 


@opvright 


em crc cr as 
mcm crm cmc ccc a i 


FireCallDlgCls 
ates FireCall dialog box 


Make sure related *.dll 
e on path. 
Mustafa ESER 


(Cogs 12) Sey 


fi] All Rights Reserved 


class FireCallDlgCls 
{ 


private: 


RECT cWnd; 
PPolarWndCls 
PShiftWndCls 
PGridWndCls 
PSuppressionWndCls 
PTComboBox 
PTComboBox 
PTComboBox 


mio lic: 
FireCallDlgCls (PTWi 


65 PS ik 


-rPireCallDlgCls(); 
Pareual void 
mircual void 
farcual void 
wrrtual void 
wirtcual void 
virtual void 
wirtual void 
warteual void 


publiave TDialog 


PolarwWnd; ¢ 
ShiftwWnd; 
GridWnd; 
SuppressionwWnd; 
Gomborrom: 
ComboType; 
ComboSize; 


ope OuGeouar  11re call 
//type of mission 


[7 elzesortee lement. Lor efrLect 


ndowsObject AParent, 
AName) ; 


SetupWindow(); 

RadioPolar (RTMessage) 
RadioShift (RTMessage) 
RadioGrid(RTMessage) 
RadioSuppression (RTMessage) 
ButtonOrder (RTMessage) 
ButtonView (RTMessage) 
UpdateFrom(); 


(per rest 


[ ID_POLAR] ; 
[IDLE Ret 
[ 


ID_SHIFT]; 
ID FERST De IONE 


Peers 


++ + + 


[ID_FIRST + ID VIEW]; 
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PDT SUEER ESS ION | ; 
Mbeantkse + L[D_FIREORDER] ; 


virtual void UpdateSize(); 
virtual void UpdateType(); 
virtual void UpdateTargetDatabase() ; 


jf B32 23S 2S SS = Se 
// class PolarWndCls 
// 
// Purpose = Child window for Firecallpljeilee 
es Displays polar location type controls. 
ae 
// Notes 
hi 
// Copyright: Copyerent (ec) Toos se Mustapome sr. 
ey All Rights Reserved 
J (HB BBS SS SS SSS Se a ee ee eee 
class PolarWndCls : public TWindow 
{ 
private: 

RECT WndRect; 

PTEGIt Editi ivrece tom. 

PTEdGit FALEDI stance, 

PTEdit EditUpDown; 
Dulce 

PolarWndCls (PTWindowsObject AParent, 

LPSTR ATitle, 
eepel e meng iar she Le 

~PolarWndcCls(); 

virtual void SetupWindow(); 

virtual vo1d Paint (HDG HDG, PAINTS fever... 

virtual void SetLocValues(); 
i 
// class ShiftWndCls 
Vy 
// Purpose -: Child window for Fireccallplgeter 
ie Displays shift location type controls. 
Ty. 
// Notes 
ee 
// Copyright: Copyright (c) 1993, Mustafa ESER 
ey All Rights Reserved 
a 
class ShiftwWndCils =: public Twingo. 
{ 
private: 

REC? WndRect ; 

PICombpcBox ComboFrom; 

PLE Cat EGitDirect ion; 

PTEdit EditRightLeft; 

PTEdit EditAddDrop; 
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PTEdit EditUpDown; 
PDBTargetCls DBTargets; 


Public: 

ShiftWndCls(PTWindowsObject AParent, 
LPSTR Arrvele, 
oper iees Witc soe Lic.) 

~Shiftwndcls(); 


virtual void SetupWindow() ; 

Mirteual void Paint(HDC HDC, PAINTSTRUCT &) ; 

virtual void TargetNo(RTMessage) = [ID_FIRST + ID_SHIFTFROM] ; 
wereval void SetLocValues(); 

virtual BOOL UpdateComboFrom(); 


leeclass GridwndcCls 


MeePurpose : Child window for FireCallDlgCls. 
1a Dicmlays Grid Location type controls. 


// Notes 


Mempeemyright: Copyright (c) 1993, Mustafa ESER 
ny All Rights Reserved 


class GridWndCls : public TWindow 
{ 


private: 


RECT WndRect ; 
PTEdit EditZone; 
Preait EditFEast; 
Pieaat EditNorth; 
PTEGit EditAltitude; 
Peait EditDirection; 


ule lic: 
GridWndCls(PTWindowsObject AParent, 
LPSTR ATIE le, 
Miers iit, dnt) + 


~Gridwndcls(); 

virtual void SetupWindow(); 

mietual void Paint (HDC hDC, PAINTSTRUCT &); 
Peeeual void SetLocValues(); 


// class SuppressionWndCls 


Mmeeeurpose : Child window for FireCallDloCls. 
vy Displays suppression location type controls. 


// Notes 
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// Copyright: Copyrightwce) 1993, .Mistataen- or. 


Hye All Rights Reserved 
//seetesesea aaa SS SH SS SS SS a Se SS a a a ee ee ee ee ee ee eee 
class SuppressionWndCls : public TWindow 
{ 
pirat vatee: 

RECA. WndRect; 

char Zone[5]; 

Leng Fast; 

long Nowthe 

long Height; 

PTComboBox ComboTargetNo; 

PanEeaiste Katt Pinect lon: 

PDBTargetCls DBTargets; 

char Description (soo, 
Dub lite. 


SuppressionWndCls (PTWindowsObject AParent, 
LPSTR ATitle, 
Ant). Int js ite wee 

~SuppressionWndCls(); 


virtual void SetupWindow(); 
virtual void Paint(HDC hDC, PAINTSTRUCT &); 

virtual void TargetNo(RTMessage) = [ID_FIRST + ID_TARGETNO] ; 
virtual void SetLocValues(); 
virtual BOOL UpdateComboTargetNo() 
virtual char *GetTargetDescription ( 


. 
f 
3 


ee 
// class FireOrderDlgCls 
// 
// Purpose : Demonstrates FireOrder dialog box 
Ti 
// Notes > It work with Paradox Engine, make sure related *.dll 
// files are on path. 
ee , 
// Copyright: Copyright (c) 1993, Mustafa ESER 
77 All Rights Reserved 
eee 
class FireOrderDlgCls = {public Vipialog 
{ 
private: 
gic MainGun; 
aLIG Ne GunNo[ 8]; 
char Zone([8] [3]; 
long Baste ic 
long NoOnti 2 ir 
long Height [8]; 
PTComboBox ComboUnitiorare- 
PTList Box ListGuns; 
PTButton ButtonAdjustingElement ; 
PDBGunCls DBGuns; 
je bodlale = 
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FireOrderDlgCls(PTWindowsObject AParent, 

LPSTR AName ) ; 
~FireOrderDlgCls(); 
virtual void SetupWindow(); 
virtual void MTO(RTMessage) CPD i RSt 4 po MTro | 
virtual void ProcessForFire (RTMessage) PibsE i Rel = lp PROCESS ]- 
virtual void UnitToFire(RTMessage) Slip FIRST + ID UNITTOF IRE) ; 
virtual void AdjustingElement (RTMessage) =[ID_FIRST 

ID_ADJUSTINGELEMENT J ; 


+ 


virtual BOOL UpdateComboUnitToFire() ; 
virtual BOOL UpdateListGuns(); 
Waeetial void CollectData(); 


een ee a eS Se SS ee SS SS SS SSS SSS SS SSS 
77 Class MTOD1gCls 

ii 

// Purpose : Demonstrates message to observer dialog box 

jas 

// Notes >: It work with Paradox Engine, make sure related *.dll 

// files are on path. 

// 

Mmeme@epyright: Copyright (c) 1993, Mustafa ESER 

as All Rights Reserved 

eres lee ee SS SS SS SS SS SS SS SS SS SS SSS 


Sees MPODIgCls : public TDialog 


{ 
public: 


MTODl1gCls(PTWindowsObject AParent, 
LPSTR AName) ; 

~MTODIgCls(); 

virtual void SetupWindow() 

i 

virtual void Ok(RTMessage) 

virtual void Cancel (RTMessage) 


Piss LPO ki|\: 
PEbot RST. 1 DeANCE ||; 


ee 
// class SubFireCallDlgCls 

We 

// Purpose : Demonstrates subfire call dialog box 

J 

// Notes Sle Work Witieraradox Engine, make sure related *.dl1l 

a7 files are on path. 

as 

Mmemeopyright: Copyright (c) 1993, Mustafa ESER 

ia All Rights Reserved 
ee 


eieates SuUbFireCallDlgCls : public TDialog 
{ 


private: 
PTEdit EditDeviation; 


PTEdit EditDistance; 
PTEdit EditHOB; 
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PTButton ButtonProcess; 
publre: 


SubFireCallDlgCls (PTWindowsObject AParent, 
LPSTR AName) ; 

~SubFireCallDlgCls(); 

virtual void Process (RTMessage) 

virtual void Cancel (RTMessage) 

virtual void Help(RTMessage) 


[ID_FIRST + ID_PROCESS]; 
[I DIBIReT = sIbPeaNer rr 
[ID_FIRST + IDHELP]; 


ee ee Se 
// class TOTAtTimeDlgCls 

le 

// Purpose : Demonstrates (time on target) At Time dialog box 

fe, 

jf Netes >: It work with Paradox Engine, make sure related *.dll 

i} files are on path. 

// 

// Copyright: Ceopyrignew (ce) 51292 Musca eame Eo 

top All Rights Reserved 

//seeaeaeaeeasaeeeeee5 S55 SS 22 22 2S tee See eee See eee eS == === === 


class TOTAtTimeDlgCls : public TDialog 
{ 


private: 


PTEdit EditHour; 
PTEdit EditMinute; 
PTEdit EditSecond; 


bul iive: 


TOTAtTimeDlgCls (PTWindowsObject AParent, 
LPSTR AName) ; 

~TOTAtTimeDlgCls(); 

virtual void SetupWindow(); 

virtual void Ok(RTMessage) 

virtual void Cancel (RTMessage) 

virtual void Help (RTMessage) 


[ID_FIRST + IDOK]; 
[ID VERST = lDeANeriaie 
[ID_FIRST + IDHELP]; 


A 
// class TOTAfterTimeDlgCls 

// 

// Purpose : Demonstrates (time on target) After Time dialog box 

a 

// Notes : It work with Paradox Engine, make sure related *.dll 

// files are on path. 

fay. 

// Copyright: Copyright (c) 1993, Mustafa ESER 

He All Rights Reserved 
ee 


class TOTAtterTimeblg€ls 4 oulbblve sf Preilod 
{ 


private: 
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PTEdit EditHour; 
PTEdit EditMinute; 
PTEdit EdaditSecond; 


Bul lic: 


TOTAfterTimeDlgCls (PTWindowsObject AParent, LPSTR AName) ; 
~TOTAfterTimeDlgCls(); 

virtual void SetupWindow() ; 
virtual void Ok(RTMessage) 
virtual void Cancel (RTMessage) 
virtual void Help(RTMessage) 


[ID_FIRST + IDOK]; 
[ID_FIRST + IDCANCEL]; 
[ID_FIRST + IDHELP}; 


femoat FIRE H 


Listing A.5: GLOBALS.H header file 





nan Reena A AER EKER ERE AREER EEA ER EAE RE KEKE RERAEEKKE 


as 

A globals.h 

aes 

// header file for global variables, objects and 
a ComputationCls 


eee eR RRL ERE EERE EKER KEK EEE ERE REEKEERERE 


#ifndef __GLOBALS__H 
# define __GLOBALS__H 


Teme lude <string.h> 
Pee lude “dbtbhl £-.h’ 


#define SUCCESS 1 
fmoerine FAIL 0 


enum MissionType {mADJUSTFIRE, 
me TREPOREEFECT, 
MmoUPPRESS ICN; 
mIMMEDIATESUPPRESSION, 
mIMMEDIATESMOKE} ; 


enum LocationType {POLAR, 
Sailer, 
GRID, 
SUPPRESSION} ; 


enum SheafType (CONVERGED, 
PARALLEL, 


SPECIAL, 


OPEN} ; 
enum TimingType {WHENREADY, 
ATMYCOMMAND, 
ATTIME, 
Aba eRe EME); 
//sestesssSS SSS SS 2S 25 SSS 55555 S255 555 SS 5555S SSS SS SS HS Se Se a a a 
//SEEUCE Gun 
es 
// Purpose : Holds @intormation forse gun 
i 
// Notes : 
las 
// Copyright: Copyright “(c) 1993 9 Musearasr oar 
as All Rights Reserved 
| a 


SErUCE. Gila 


{ 


tate GunNo; 


//gun lecatioen 
char zone[5]; 
double East; 
double North; 
double Height; 


//firing command elements 
double Timing; 

devble Der leceian- 

double Blevatien, 

Gouble Quadrant; 


//target-hit info 

char HitZone [5]; 

double HitEast; 

double HitNorth; 

double Hraeherqnie- 

double HitRange; 

double HitDeflection; //chart deflection 
double HitAzimuth; 7//gun-hit pointe vazomene. 


//gun general info 
double CommonOrientation; 


//_CLASSDEF (ComputationCls) 


ee 
// class ComputationCls 

yal 

// Purpose : Makes all the computations for a gun battery fire direction 
ee 

// Notes : It works with Paradox Engine, so necessary *.dll files 
ie should be on path. 

ee 

// Copyright: Copyright (c) 19935) Mistatay bom 

77 All Rights Reserved 

/ /smee3eetaeer rr eee eee eee eee = - = = = = = === 
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_ 


class Computationcls 


{ 


private: 


WStr 
WStr 


FiringTableName ; 
FiringCharge; 


PPBTable F Cls DBTable_F; 


Public: 


char 
char 
char 
char 
char 


BatteryName [3]; 
Ga liiane (4 | (20 ]- 
OrderLine[80]; 
MTOLine[80]; 
SubCal lbine (50); 


Peeepserver information 


char 
char 
double 
double 
double 
double 


ObserverName [10]; 
ObserverZone[10]; 
ObserverEast; 
ObserverNorth; 
ObserverHeight ; 
SllPrrect:10n; 


//target location before adjustment 


char 

double 
double 
double 
double 
double 


IniTargetZone[3]; 
IniTargetEast; 

IniTargetNorth; 
IniTargetHeight; 
IniTargetRange; //for main 
IniTargetDeflection;//for main 


//target location after adjustment 


ehar 


CurrTargetZone [3]; 


double CurrTargetEast; 
double CurrTargetNorth; 
double CurrTargetHeight; 


//target location settings 


i 


//polar 


double 
double 
// 

Py grid 
enar 


PolarDistance; 
PolarUpDown ; 


GraaZene [3]; 


double GridEast; 
Bouble GridNorth; 
double GridHeight; 


af 


Pyshift 


char 
char 
double 
double 
double 
double 
double 
double 
yf 


Shorter rom | 10]; 
ShiftZone[10]; 
ShiftEast; 
Sarre North- 
StattHeioht: 
ShiftRightLeft; 
ShiftAddDrop; 
ShiftUpDown; 


//suppression 


char 


Supp largetNo| 10]; 
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gun 
gun 


ehax Descriptromer sc). 
Ges Category [80]; 


//fire command settings 
int NoOfPiecesToFollow; 


//eurrent valves 


char CurrFrom[10]; 

char CurrMissionType[50]; 
char GurrSiaze| bol, 
LocationType CurrLocationtType; 
SheafType GUY eiear. 

//gun parameters 

Gun Guns [3 

erate MainGun; 


double AZ imuehnoOrraiire. 


//gun - ammo 
double BurstDiametre: - 


//fire commands buffers 
int FiredNo; 


ComputationCls(); 
~ComputationCls(); 


virtual void Cemputehitececers (7; 
virtual void ComputeChartValues(); 
virtual void ComputeRangeAzimuth(double xl, 


deuble iy 
double. x27 
double yd, 


double &Range, 
double &Azimuth) ; 
virtual void ComputeCoordinate(double xl, 
double) yi; 
double Range, 
aeouble we AzZzamucn: 
double &x2, 
double &y2); é 
void SetFiringTableName(WStr FTName) ; 
WStr GethiringCharget); 
BOOL ComputeFiringCharge(); 
BOOL ComputeElevations(); 
BOOL ComputeFiringValues(); 


void Reset(); 


ee 


#endif _ GLOBALS__H 


Listing A.6: REPORT.H header file 





[LER RRR ERRRRRERREEREKEEEKREKKAREKK RARE A AX Ee ee ee 


// 
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// giz jolene] zany g\ 


of 
// header file for the classes ReportWndcls, 
vy TextWndcCls 


re eee ae RAK RRR RAKE RARER EER EERE EERE KKEEEKE KE 


#ifndef __REPORT_H 
# define __ REPORT_H 


// Note the following code is only executed if 
// this file has not been previously included 


miioeiiude “fire.h” 


#define ID_PRINT 101 


_CLASSDEF (ReportWndCls) 


_CLASSDEF (TextWndCls) 
ee eee SS SS SS SS SS 
// class ReportWndCls 
yor 
// Purpose : Hosts a canvas window which displays the firig report 
ims 
// Notes 
ak 
Mempeopyright: Copyright (c) 1993, Mustafa ESER 
oy All Rights Reserved 
i 
class ReportWndCls : public TWindow 
{ 
private: 
RECT WndRect; 


PTextWndCls TextWnd; ' 
PeuvetonZCls ButtonPrint; 


meublic: 
ReportWndCls (PTWindowsObject AParent, 
IOesSei Ges ATitle, 
AACE ve 
ata Y, 
shy giie Sue 
i gWe CSO) s 


~ReportWndCls(); 

virtual void SetupWindow(); 

Virtual void Paint (HDC PaintDC, PAINTSTRUCTS) ; 

Virtual void Print (RTMessage) = [ID_FIRST + ID_PRINT]}; 
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// class TextWndCls 
ie 
// Purpose : Serves as a canvas to display the firing report 
is 
// Notes 
as 
// Copyright: Copyright(c) 19933) Mustatarior. 
la All Rights Reserved 
//eesestn tases 22S 225225 S855 2== 5522-5 25 = = = = = = = = eee 
class TextWndCls : public TWindow 
{ 
private: 
REG. WndRect; 
pubiline: 
TextWndCls(PTWindowsObject AParent, 
LPSTR paiMaige Ikrey 
ay ts x 
EVE Y, 
nih g's ax, 
arti ay 
~TextWndcCls(); 


virtual void SetupWindow(); 
virtual void Paint(HDC PaintDC, PAINTSTRUCTS) ; 


#endif _ REPORT_H 


Listing A.7: SELECT.H header file 





[LL RRRRRRRERRREEKEKREKERREKKEEKEKRKEEKKERKEKKKR AA RK EK EE RARE eee 


1s selecects 


// header file for the class SelectionWndCls 


é 
[ [RR RE RRR ERRERERK REAR ERAERRKK RRA ES Re eee 


#ifnder = SELECT HA 
# define SELECT FA 


// Note the following code is only executed if 
// this file has not been previously included 


finceivde “five.n/ 

#include “command.h” 
fanelude “burstsc-h” 
#include “report.h” 
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Peetine ID EXIT 101 
feeraine ID HELP 102 


fmtrem fFire.cpp 

extern PCommandWndCls Commandwnd; 
extern PBurstsWndCls BurstsWnd; 
extern PReportWndCls ReportWnd; 


_CLASSDEF (SelectionWndcls) 


// class SelectionWndcls 

f/f 

// Purpose : Displays notebook tab-stops to select different windows. 
cy 

// Notes 


as 
Mmemeoevright: Copyright (c) 1993, Mustafa ESER 
lad All Rights Reserved 


class SelectionWndCls : public TWindow 
{ 


private: 


PTWindowsObject MainWnd; 


RECT WndRect ; 
POINT IndexTab[3] [4]; 
short GurrindexTab-: 
PButton2Cls ButtonExit: 
PButton2Cls Bur GonHelp; 
mublic: 
SelectionWndCls (PTWindowsObject AParent, 
LPSTR AT le? 
ae tate xX, 
Tg ge ee 
ne ax, 
aati ely); ’ 
~SelectionWndCls(); 


virtual void SetupWindow(); 

Virtual void Paint(HDC PaintDC, PAINTSTRUCTS) : 

virtual void WMLButtonDown(TMessage &) (WM FIRST + WM _LBUTTONDOWN] ; 
Virtual void Exit (RTMessage) [ID_FIRST + ID_EXIT]; 
Virtual void Help(RTMessage) [ID_FIRST + ID_HELP] ; 


#endif 


i) 


APPENDIX B. (OCHART HEADER FILES LISTINGS) 


Listing B.1: ABSLIST.H header file 


J [RRR ER RRR ERR EKEEREARK EKER EK HRN Ne 


Ty, 

// abslist.h 

a 

// header file for the class genAbstractList 


[LEER RERRRRERE RAE EAE RRA AE Ee AR ee eee 


#ifndef ABSCESS ae 
# define _ABSLIST_H 


//note that the following code is executed only 
//if this file has not been previously included 


#define ALLOCATE_ERROR “Dynamic allocation error” 


enum boolean { false, true }; 


typedef char Strings sli 


/ / Bee B SBS 53 S528 25S 55S = SS HS SH SS Sa SS Se Se ee a ee ee ae ee ee ee ee ee SS SS SS 
// template class genAbstractList 

ue 

// Purpose : implements an abstract class of linked lists with 

je: the following operations and features: 

Li 

// > nodes with duplicate keys can be allowed. 

Le > insert new node. 

// > search for a node with a specific occurrence 

// of a key. 

// > delete a node with a specific occurrence of a Key. 

he > traverse the nodes of the lists. 

ye the user to modify them. 

ye 

// Notes 

// 

// Copyright: Copyright (c) 1993, Mustafa ESER 

fe All Rights Reserved 
ee ee eee 


template<class T> 
class genAbstractList 


protected: 
unsigned listSize; // number of nodes 
boolean overwrite; // overwrite data flag 
boolean hasDuplicate; // Auplicate-key flag 
string80 errorMessage; // error message 


a2 


public: 
//state query methods 
boolean isEmpty () 
{ 


} 


meer (listSize == 0) ? true : false; 


unsigned getListSize() 


{ 
} 


meewrn listSize: 


char* getErrorMessage() 


{ 


string80 s; 
strcepy(s, errorMessage) ; 
PiatorMessage([0)] = ‘\0'; 


i@eeulrn Ss; 


//object manipulation methods 
genAbstractList () 
{ } 


wma l boolean insert (T&) 


{ 
} 


return false; 


virtual boolean remove(T&, unsigned occur 


{ 
} 


return false; 


Virtual boolean search(T&, unsigned occur 


{ 
} 


return false; 


Mairtval boolean visitFirstNode(T&) 


{ 
} 


return false; 


Virtual boolean vVisitNextnNode (1a) 


{ 
} 


return false; 


Virtual Vvoltdeelear | 


{ } 


#endif _ABSLIST_H 


Listing B.2: CHART.H header file 


[RRR RRR RRR ERE RRR ER ERR RRR ee 


Se 

La chatreal 

(ee 

// header file the classes GridSetupDlgCls 
a) TargetSetupDlgCls 
Ta GunSetupDlgCls 

// NewEntryDlgCls 

La NewFromEntryDlgCls 
la GunInputDlgCls 

jee TargetInputDlgCls 
jae TargetDBDlgCls 

es GunDBD1gCls 


[ [BREE RRR RARER KR ERE EER REE RRS EO eee 


#ifndef = CHARTS 
# define 2e5CHAR Ta 


//note that the following code is executed only 
//if this file has not been previously included 


#include 
#include 
#include 
Hie Mice 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#1 nc luce 
#include 


<owl .h> 
<edit.h> 

Fadl mone) oleb <1 a3 
<COmMbC box ane 
<dia log .h- 
<bwece he 
<button -h> 
<string.h> 
<statie sh] 
<scroldbanh= 
<DeChKbOx i= 
<bradio.h> 


“defines.h” 
“globals.h” 
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Pemeiude “targetdb.h” 
pepe tude “gundb.h” 


RS SS SS SSS 
// class GridSetupDlgCls 
Lf 
// Purpose : Displays grid setup dialog box. 
ag 
// Notes 
a 
Mmempeepyright: Copyright (c) 1993, Mustafa ESER 
a All Rights Reserved 
es See SR Se i ee oo 
class GridSetupDlgCls : public TDialog 
{ 
private: 
PTEdit EditZone; 
PTEdit EditLeft; 
PTEdit EditRight; 
PTEdit EditBottom; 
Paeait Batelop: 


PTComboBox ComboDistance; 
PTComboBox ComboScale; 
PTCheckBox CheckShowGrid; 
PTCheckBox CheckShowNorth; 


public: 


GridSetupDlgCls(PTWindowsObject AParent, LPSTR AName); 
~GridSetupDlgCls(); 

virtual void SetupWindow() ; 
virtual void Ok(RTMessage) 
Virtual void Cancel (RTMessage) 
virtual void Help(RTMessage) 


PPD ar Phe Tl se oOK |; 
[ID_FIRST + IDCANCEL] ; 
[PRSEiRST + IDHELP); 


// class TargetSetupDlgCls 


// Purpose : Displays target setup dialog box. 


Mmepeopvyright: Copyright (c) 1993, Mustafa ESER 
yf All Rights Reserved 

class TargetSetupDlgCls : public TDialog 

{ 


private: 
PTCheckBox CheckShowTargets; 
mublic: 


TargetSetupDlgCls (PTWindowsObject AParent, LPSTR AName) ; 
~TargetSetupDlgCls(); 


25) 


virtual void SetupWindow(); 
virtual void Ok(RTMessage) 
virtual void Cancel (RTMessage) 
virtual void Help(RTMessage) 


[ID_FIRS® + Lec 
[ID_FIRST + IDGANCER]: 
[ID_ FIRST = Teepe 


/7 “elaec GunSetupDlgCls 
// Purpose : Displays gun setup dialog box. 
// Notes 


// Copyright: Copyright) (ec) 1393 iuseataseoe 
ys All Rights Reserved 


class GunSetupDlgCls : public TDialog 
{ 


private: 


PTComboBox ComboScale; 
PTCheckBox CheckShowCoverings; 


jolo Abilene 


GunSetupDlgCls (PTWindowsObject AParent, LPSTR AName) ; 
~GunSetupD1gCls(); 

virtual void SetupWindow(); 
virtual void Ok(RTMessage) 
virtual void Cancel (RTMessage) 
virtual void Help(RTMessage) 


[ID FIRST + IDOK]; 
[ID FIRST + IDCANCEDIE 
[ID_FIRST + IDHELP]; 


Ye a ee SS 
// class NewEntryDlgCls 
La 
// Purpose : Displays new entry dialog box. é 
aes 
// Notes 
// 
// Copyright: Copyright (c) 1993, Mustafa ESER 
Ef All Rights Reserved 
a 
class NewEntryDlgCls : public TDialog 
protected: 
ong NewX; 
ikevave; NewyY ; 


PTRadioButton RadioTarget; 
PTRadioButton RadioGun; 
PTRadioButton RadioRadar; 
PTRadioButton RadioObservationPost; 
PTRadioButton RadioRegPoint; 
PTRadioButton RadioCheckMark; 
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public: 


NewEntryDlgCls (PTWindowsObject AParent, 


LPSTR AName, 
long X, 
long NO 


~NewEntryDlgCls() ; 

virtual void SetupWindow() ; 
Virtual void Ok(RTMessage Msg) 
virtual void Cancel(RTMessage Msg) 


[ID_FIRST + IDOK]; 
[ID FIRST + IDCANCEL]; 


Wot 


I ee SS SS 
// class NewFromEntryDlgCls 
// 
// Purpose : Displays new from entry dialog box. 
if 
// Notes 
gs 
// Copyright: Copyright (c) 1993, Mustafa ESER 
ie All Rights Reserved 
eS SS = SS ES 
class NewFromEntryDlgCls : public NewEntryDlgCls 
{ 
private: 
long Fromx; 
long Fromy ; 
rat OffAzimuth; 
long OffDistance; 


PTEdit EditEast; 
PTEdit EditNorth; 
PTEdit EditAzimuth; 
PTEdit EditDistance; 


public: 
NewFromEntryDlgCls (PTWindowsObject AParent, 
LPSTR AName, , 
long XxX, 
long Via 
Aitate Azimuth, 
tern Distance); 


~NewFromEntryDlgCls(); 

virtual void SetupWindow(); 
virtual void Ok(RTMessage Msg) 
virtual void Cancel (RTMessage Msg) 


{ID_FIRST + IDOK}; 
fID_FIRST + IDCANCEL]; 


// class GunInputDlgCls 


femeurpose : Displays gun input dialog box. 


// Copyright: Copyright (c) 1993, Mustafa ESER 


oF, 


All Rights Reserved 


emcee cc ee ee ee ce ce ce ec ec ce cc cc ce cc ce cc cc cw ce we we es es es ees ee 
cme crm cmc ccc ccc ce ce epee cp crc cre cece ce cc ce me cm mc cme cr ce ce ce ce ce ee ec ee ee es ee ee ee ee ee ee ee 


class GunInputDlgCls : public TDialog 
{ 


private: 

GunDBCls aGun; 

PTEdit EditEast; 

PTEdit EditNorth; 

PTEdit EditHeight; 

PTEdit EditRange; 

PTEdit EditLeft; 

PTEdit Beli tracine: 

PTEdit EditCommonDef ; 

PTEdit EditOrientation; 

PTComboBox ComboBattalion; 

PTComboBox ComboBattery; 

PTComboBox ComboGun; 

PTComboBox ComboGunType; 

PTBCheckBox CheckMainGun; 

pubic. 

GunInputDlgCls(PTWindowsObject AParent, 
LPSTR AName, 
long vee 
long vole 

GuniInputDlgCls(PTWindowsObject AParent, 
LPSTR AName, 
GunDBCls Gun) ; 


~GunInputDlgCls(); 
virtual void SetupWindow(); 


Virtual 
Virtual 
Virtual 


void Ok(RTMessage Msg) 
void Cancel (RTMessage Msg) 
void Help(RTMessage Msg) 


[ID_FIRST + 2bCky 
[ID_FIRST + IDCANCEL] ; 
[ID_FIRST + IDHELP]; 


ee ee 
// class TargetInputDlgCls. 
Va 
// Purpose : Displays target input dialog box. 
// 
// Notes 
// 
// Copyright: Copyright (c) 1993, Mustafa ESER 
Ye All Rights Reserved 
//seaereat eee HHH Se He eH HS SSS SS SS SS HSH HS SS er Ser HE SHS Se Se eS He Se eS SSeS eet SHES 
class TargetInputDlgCls public TDialog 
{ 
private: 
TargetDBCls aTarget; 
PrEdie EditTargetNo; 
PTEdit EditEast; 
PTEdit EditNorth; 
PTEdit EditHeight; 
PTEdit EditDescription; 
PTComboBox ComboCategory; 
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euelic: 


TargetInputDlgCls(PTWindowsObject AParent, 


LPSTR AName, 

long IF 

long ae 
TargetInputDlgCls (PTWindowsObject AParent, 

LPSTR AName, 

TargetDBCls Mats}? 


~TargetInputDlgCls(); 

virtual void SetupWindow(); 
virtual void Ok(RTMessage Msg) 
virtual void Cancel(RTMessage Msg) 
virtual void Help(RTMessage Msg) 


[ID_FIRST + IDOK]; 
[ID_FIRST + IDCANCEL] ; 
[ID_FIRST + IDHELP]; 


// class TargetDBDlgCls 


// Purpose : Displays target database dialog box. 


femeopyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 


Secs TargetDBDlgCls : public TDialog 
{ 


private: 


PTList Box ListNames; 
PTWindowsObject MainWnd; 


mulolic: 


TargetDBDlgCls (PTWindowsObject AParent, 
EPSTR AName) ; 

~TargetDBDIgCls(); 

Virtual void SetupWindow(); 

virtual void UpdateListBox(); 


virtual void ButtonAdd(RTMessage) = Pier Rote Lowa Dh |; 
virtual void ButtonDelete(RTMessage) = [ID_FIRST + ID_DELETE]; 
Virtual void ButtonDetail(RTMessage) = [ID_FIRST + ID_DETAIL]; 
virtual void ButtonShow (RTMessage) =| Dehli Rok: + [Dp SHOW]; 
virtual void Cancel (RTMessage) = [ID_FIRST + IDCANCEL]; 
virtual void Help(RTMessage) = lUshERST e+. LOHELP |); 

1 

/ Jfeertrtttettt tres SSS SS ee ee ee ee te ee ee ee eer rer eee eee = === 

// class GunDBDlgCls 

iy 

// Purpose : Displays gun database dialog box. 

Ly 

// Notes 

a 

fm Copyright: Copyright (c) 1993, Mustafa ESER 

V7 All Rights Reserved 


oo 


class GunDBDlgCls 
{ 


private: 


public TDialog 


PTList Box ListNames; 
PTWindowsObject MainWnd; 


publiae: 


GunDBD1lgCls (PTWindowsObject AParent, 
LPSTR AName) ; 

~GunDBDI1gCls(); 

virtual void SetupWindow(); 

virtual void UpdateListBox(); 


virtual void ButtonAdd(RTMessage) = {ID_FIRST + ID_ADD]; 
virtual void ButtonDelete(RTMessage) = [ID_FIRST + ID_DELETE] ; 
virtual void ButtonDetail(RTMessage) = [{ID_FIRST + ID_DETAIL]; 
virtual void ButtonShow(RTMessage) = {ID_FIRST + ID_SHOW]; 
virtual void Cancel (RTMessage) = [{ID_FIRST + IDCANCEL]; 
virtual void Help(RTMessage) = [ID_FIRST + IDHELP]; 


#endif _ CHART_H 


Listing B.3: DEFINES.H header file 





LL RRR KEKEKEKEKEEKEEKEEREREREKREEKKERERREREREEEKERKKKEKKKEKEKEKK AE 


// 
es defines.h 


// neader Eile torederines 
LL RRR RRR EREKRKEKEEKKEKREKKEKKKEEKEKKEKEKEKKKEREEKEEKRKKKEKKEKEKKKKEKKKKKKKE K © Re 


#ifndef __DEFINES_H 
# define __DEFINES_H 


//menu identi e& vers 


#define CM_TRAININGMODE dO: 
#define CM_EXITCHART 109 
#define CM_INSERT 203 
#define CM_INSERTFROM 204 
#define CM _GRIDSETUP 303 
#define CM_TARGETSETUP 304 
#define CM_GUNSETUP 305 
#define CM_SAVEONEXIT 309 
#define CM_DATABASETARGET 401 
#define CM _DATABASEGUN 402 
#define CM_ABOUT 15). 
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mento window menu identifiers 


#define CM _SCALEONE 801 
#define CM_SCALETWO 802 
#define CM _SCALETHREE 803 
#define CM_SCALEFOUR 804 
#define CM_SCALEFIVE 805 
#define CM_SCALESIX 806 
//Grid setup dialog window 

#define ID_ZONE ae 
feetine ID LEFT 105 
#define ID_BOTTOM 106 
#define ID_RIGHT oy 
#define ID _TOP 108 
#define ID_DISTANCE 204 
#define ID_SCALE 110 
#define ID _SHOWGRIDLINES Od 
#define ID _SHOWNORTHSIGN LO 


//TargetSetupDlgCls dialog window 
#define ID_SHOWTARGETS 110 


//GunSetupDlgCls dialog window 
#define ID_SHOWGUNCOVERINGS 101 


//NewEntryDlgCls dialog window 


#define ID_TARGET OA 
#define ID_GUN 102 
#define ID RADAR 103 
#define ID_OBSERVATIONPOST 104 
#define ID _REGPOINT LOS 
#define ID _CHECKMARK 106 


//NewFromEntryDlgCls dialog window 
foeeeuses 1d east, id_north, id_target, id_gun, id_others as well 
#define ID_EAST 201 


#define ID NORTH 202 
#define ID_AZIMUTH 203 
#define ID _OFFDISTANCE A AlaR 
//GuniInputDlgCls dialog window : 
#define ID _MAINGUN 999 
#define ID _BATTERYNAME 1000 
#define ID_GUNNO TOOL 
#define ID _BATTALIONNAME LOOZ 
#define ID _GUNTYPE LECIO S 
#define ID_HEIGHT 1009 
#define ID _MAXRANGE 1010 
#define ID _MAXLEFT aay 
#define ID _MAXRIGHT Ga 
#define ID_COMMONDEF uk(erare! 
#define ID_ORIENTATION 1014 
//TargetInputDlgCls dialog window 
#define ID_TARGETNO 103 
#define ID DESCRIPTION OF 
#define ID_CATEGORY 108 


//TargetDBDlgCls dialog window 
#define ID_NAMES Aes 
#define ID_ADD sey 
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#define ID_DELETE 1L18) 
#define ID_DETAIL 104 
#define ID_SHOW LOS 


#endif _ DEFINES_H 


Listing B.4: GEN2LIST.H header file 





[JL RR RR RRRRRERRRKEEEAREKERREKEREKRRARREREK ERA R RAKE eee 


se 

iy gen2list.h 
fed, 

// header file for the template classes 
ye genOdList 

igs genUdList 


[ [RRR REE EREEEREEEARE EERE ERE EERE eee 


#ifndef SGENZI Stan 
# define _GEN2LIST_H 


//note that the following code is executed only 
//if this file has not been previously included 


#include “abslist.h’ 


template<class T> 

struct dListNode { 
T dataNode; “ 
dListNode<T> *prevPtr; 
dListNode<T> *nextPtr; 


de 
// template class genOdList 

ye 

// Purpose : implements a classes of ordered doubly-linked lists 
i with the following operations and features: 

ye 

ie > nodes with duplicate keys can be allowed. 

(ey > insert new node. 

if > search for a node with a specific occurrence 

Ne of a key. 

oi > delete a node with a specific occurrence of a key. 
i > traverse the nodes of the lists. 

17 
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// Notes 


je 

feecopyright: Copyright (c) 1993, Mustafa ESER 

7/ All Rights Reserved 

ce a ee eee ee SS = == == 


template<class T> 
class genOdList : public genAbstractList<T> 
{ 


protected: 
dListNode<T> *nodePtr, // node-visitation pointer 
tai // pointer to the tail of list 
*head; // pointer to head of list 
AE Liebe // buffer 


genOdList<T>& copy (genOdList<T>&) ; 
ol 1c : 
//state manipulation methods 


genOdList() 
ce 


genOdList (boolean canoverwrite, boolean allowduplicate); 


genOdList (genOdList<T>& dl) 
{ 


} 


head = NULL; copy(dl); 


~genOdList () 
{ 


clear(); 


void setNodePtr (dListNode<T>* listPtr) ; 


void setBuf1l(T& newBufl) 


_bufl = newBufl; 


//state query methods 
dListNode<T>* getNodePtr() 
{ 


} 


return nodePtr; 


//object manipulation methods 
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virtual boolean insert(T&); 
virtual boolean remove(T& x, unsigned occur = 1); 


virtual boolean search(T& x, unsigned occur = 1) 


dListNode<T> *p; 
return search(p, x, occur); 


} 


virtual boolean search(dListNode<T>* &thisptr, 
T& xX, 
unsigned OCeUB =m in 


virtual boolean visitFirstNode(T& x); 
boolean visitPrevNode(T& x); 

virtual boolean visitNextNode(T& x); 
boolean visitLastNode(T& x); 

Virtual void clearl- 


genOdList<T>& operator =(genOdList<T>& dl) 
{ 

copy (air 

return “thas: 


//snestess2 222222222222 52 222525252 52525252525 >2= 25222522 22>=-—=_—_—_—_——_—_——— — — eee 
// template class genUdList 

les 

// Purpose : implements a classes of unordered doubly-linked lists 
if with the following operations and features: 

// 

es > nodes with duplicate keys can be allowed. 

fa > insert new node. : 

es > search for a node with a specific occurrence 

17, of a key. 

as > delete a node with a specific occurrence of a key. 
// > traverse the nodes of the lists. 

avs 

// Notes 

ff 

// Copyright: Copyright (c)  199s3MuctaraecER 

Vow All Rights Reserved 
ee 


template<class T> 
class genUdList : public genOdList<T> 


{ 
Dubie: 


//state manipulation methods 
genUdList() {} 


genUdList (boolean canoverwrite, boolean allowduplicate) 
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:genOdList<T>(canoverwrite, allowduplicate) 


an) 


genUdList (genUdList<T>& dl) 


mead) = NULL; copy(dl); 


//object manipulation methods 
virtual boolean insert (T&) ; 
virtual boolean search(dListNode<T>* &thisptr, 
T& x; 
unsigned occur = 1); 


genUdList<T>& operator = (genUdList<T>& dl) 
{ 

eepy (dl); 

meturn *this; 


#endif _GEN2LIST_H 


Listing B.5: GLOBALS.H header file 





is AX KKK AKKEKARKKAKKE ER ERE KEK AKAKKEAKEEA KK EKKKKKEKEEKKKKEK KE 


ie 

iy globals.h 

Tey 

Pyeeneader file for the class GlobalCls and varibals 


ee re EK RK R KARE RRR ER KARR EER REE AKEEEREER ERK EERE KEKE KK 


#ifndef __GLOBALS_H 
o define __ GLOBALS_H 


//note that the following code is executed only 
//if this file has not been previously included 


#define FACTORSLIDE 250//the bigger the slower 
ee 
// class GlobalsCls 

// 

// Purpose : Holds the global objects and variables for the rest of 


ier, the application. 


TH 

// Notes 

Tay 

// Copyright: Copyright (¢)" 1993) Mustataeeoon 

iy All Rights Reserved 

VA | a ee 

class GlobalsCls 

{ 

public: 
long WCLeft, WCBottom; //lower left most coors of world 
long VisibleWCLeft; //left-most coordinate of screen 
long VisibleWCBottom; //bpottom-most coordinate of screen 


long WCToRightExtension;//just for scroll bars limitations 
long WCToTopExtension; //just for scroll bar limitations 

ne ghe Distances [5]; 

Hehe CurrDistanceIndex; 

short DistancesCount; 

long Scales[6]; 

avane CurrScaleIndex; 

short ScalesCount; 

BOOL ShowGrids; 

BOOL ShowNorthArrow; 

BOOL ShowTargets; 

BOOL ShowGunCoverings; 

BOOL SaveOnExit; 

iit MinScaleNDXForGuns; 

short CurrBmpButtonSelection; //tool bar bitmap menu selections 
long SlideAmount; //scroll bar sliding amount in meters 


//main window dimensions 
int WidthMainWindow; 
a euet HeightMainWindow; 


ee re OI SS Oe 
GlobalsCls() 
Pee ee eee Cee Cee eee ee eee Sok ee 
{ 

Reset (); 
) ,; 
Tee I OB Oe 
Reset () 
TL io one ce oe bee ee WR ke Sw erase cle eae reer 
{ 

//firing chart extremum coordinates 

WCLeft = 10000; 

WCBottom = 10000; 

VisiblewCLeft = WCLeft; 

VisiblewCBottom = WCBottom: 

WCToRightExtension = 50000; 

WCToTopExtension = 50000. 

Distances [0] = SOO. 

Distances[1] =) .500- 

Distances [2] = 1000; 

Distances [3] = 2000 

Distances [4] = S000; 

CurrDistanceIndex = 2; 
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DistancesCount = 5: 

Scales [0] = 2500: 

Scales[1] = 5000; 

Scales[2] — ies oe 

Scales [3] = SLO OS 

Scales [4] = TES U00G- 

Scales [5] = LO00000 

CurrScaleIndex = ee 

ScalesCount = 6: 

ShowGrids = TRUE: 

ShowTargets = RUE 

ShowGunCoverings =e OE 

MinScaleNDXForGuns = 1; 

ShowNorthArrow B50) 

SaveOnExit = TRUE; 

CurrBmpButtonSelection = -1; //means none of them is selected 
SlideAmount = Scales [CurrScaleIndex]) / FACTORSLIDE; 
WidthMainWindow = te 00) 

HeightMainWindow = (601015 


ie 


#endif __ GLOBALS_H 


Listing B.6: GUNDB.H header file 





ee ee ee REET REE R EX REE AEEA ERE ARK ER EE 


ae gundb.h 


// header file for the class GunDEBCls 


ee EE EKER ERE REE RAR ERERE EE EREREREREEE RE ERE REE EKK 


#ifndef _GUNDB_H 
4 define _GUNDB_H 


//note that the following code is executed only 
//if this file has not been previously included 


#include <string.h> 


#define MAXNAMELEN 10 
#define MAXMODELLEN 30 


_CLASSDEF (GunDBC1s) 


7/ class GunDBCls 
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as 


// Purpose :Serves as database management class for gun database 
es 
// Notes 
LA 
// Copyright: Copyright (c) 1993, Mustafa ESER 
i All Rights Reserved 
vs ——— a a SSS SS SSS SS SS SSS 
class GunDBCls 
{ 
private: 
char BattalionName [MAXNAMELEN] ; 
char BatteryName [MAXNAMELEN] ; 
short GunNo; 
long CoorEast; 
long CoorNoren: 
qeEyte Height; 
BOOL MainGun; 
char Model [MAXMODELLEN] ; 
long MaxRange; 
mnt MaxRightDeflection; 
ali ole MaxLeftDeflection; 
int CommonOrientationDeflection; 
eats OrientationDeflection; 
public 
ee ere re re 
GunDBCl1s () 
| foo coe eee eee ww ecb we ee eS ee ee eye re ce ee arnre eee eee 


strcpy (BattalionName, “*"); 
BatteryName [0] 

GunNo 

CoorEast 

GGOrNorem 

Height 

MainGun 

strepy (Model, “*[-}*); 
MaxRange 
MaxRightDeflection 
MaxLeftDeflection 
CommonOrientationDeflection 
OrlentationDeflection 


nou wow ow 
Bs Ys FO a J 


| wa eee we Bch eRe eb OARS oe eee 
GunDBCis (char “Brn: 

char* Btr, 

int Gun, 

long East, 

long North, 

abrlite Height, 

BOOL mGun, 


char* Mod, 
long Range, 
int DefR, 
int DefL, 
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CommonDef, 
Orientation) 


strcpy(BattalionName, Btn); 
strcepy (BatteryName, Btr) ; 
GunNo 
CoorEast 
CoorNorth 
Height 
MainGun 
strcpy (Model, 
MaxRange 
MaxRightDeflection 
MaxLeftDeflection 
CommonOrientationDeflection 
OrientationDeflection 


Mod) ; 


ee 2. oe at ses ieee i es be ee eee ee ee ee 


GunDBCls (const GunDBCls& T) 


Seas eon eee ane ee ee Ae ee es 


Vy/eopy initializer 


strcpy (BattalionName, 
strcpy (BatteryName, 
GunNo 
Coorkast 
CoorNorth 
Height 
MainGun 
strcpy (Model, 
MaxRange 
MaxRightDeflection 
MaxLeftDeflection 
CommonOrientationDeflection 


T.Model) ; 


DefL; 
CommonDef ; 
Orientation; 


T.BattalionName) ; 


T.BatteryName) ; 


-GunNo; 
.CoorHast: 
*CCOrENOTrEeh: 
.Height; 
.MainGun ; 


.MaxRange; 
.MaxRightDeflection; 
.MaxLeftDeflection; 
.CommonOrientationDeflection; 


ot nes bea) Las lero Me Lope (lies | ae fit | Lao 


OrientationDeflection .OrientationDeflection; 


Pes eg ne es wc ee ee Bl se ee ee ee 
se oe 6 od BS eg ae AEE ae ne arc 


TR er Pe leo ie oes es Sin ee dSoS alge ee Ys he 6 ote Re eee ee 
GunDBCls& operator = (const GunDBCls &T) 
8 eo oa OO es 5S Be 5 Re Ein 6 See eee a a rc a arr 
{ 

strcpy (BattalionName, T.BattalionName) ; 

strcpy (BatteryName, T.BatteryName) ; 

GunNo = T.GunNo; 

CoorEast =) LecCoOoLbast ; 

CoorNorth =JPaCoonEN@neli: 

Height = ToHerght- 

MainGun = T.MainGun ; 
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strcpy (Model) i tedel)- 
MaxRange 

MaxRightDeflection 
MaxLeftDeflection 
CommonOrientationDeflection 
OrientationDeflection 


return *this- 


*oeee#ee®# eee e#e# «© ® @® @© @ @ @ emUmOMmUCmUOMUmUCUOMmUCUCUOUmUCUOUmUCUCOUmUCUOUmUCUCOUmUCUOUmUCUOUUCUOUUCUOUOUCUO 


// 


if( stremp(BattalionName, aGun. 
return J: 
jelse if (strcmp(BattalionName, 
if(strcemp(BatteryName, aGun. 
return 1; 
Jelse if (strcmp (BatteryName, 
if( GunNo < aGun.GunNo ) 
return 1; 
} 
} 


return O- 


Li 


eee eee?# 8 @#® ® @® @® ® ® @® @#® @® @® @® @® @#® @® @® @® #® @® ® @® @® @® @ 


if 


if( strcemp(BattalionName, aGun. 
return 1- 
Jelse if (strcemp(BattalionName, 
if (strcemp(BatteryName, aGun. 
return” I 
Jelse if (strcmp(BatteryName, 
1£( GunNo > aGun.GunNo ) 
return 1; 
} 
} 


return 0; 


// 


if( strcmp (BattalionName, 
return 1; 

}Jelse if (strcmp(BattalionName, 

if (strcmp (BatteryName, 

return, 

}else if (strcmp(BatteryName, 

1f( GunNo <= aGun.GunNo ) 
return 1; 


Se | 


aGun. 


aGun. 


T.MaxRange; 
T.MaxRightDeflection; 
T.MaxLeftDeflection; 
T.CommonOrientationDeflection; 
T.OrientationDeflection; 


{ 


BattalionName) < 0 ) 


aGun.BattalionName) 
BatteryName) < 0 ) 


aGun.BatteryName) 


oeoe#eeee#e tee e@#e@e@ @ @ eh emUOMmUmUCUOMmUCUOUmUCUCUOUmUCUOUmUCUOUCUCOUmUCUOUmUCUCOUmUCUCOUmUCUOUmUCUOUmUCUOMmUCUCOUCUOUOUlU 


eoeeeeeHee#e#e#e®%*e# «ee ®#e«@¢ ee @# # «# e«# @®# @® @® @® @® @® @® #* ®@® @® ® @® # @ 


BattalionNeme) > 0 


{ 


aGun.BattalionName) 
BatteryName) > 0 ) 


== 
—_—=e—_— 


aGun .BatteryName ) 


¢ 


eoeeeee### # ¢ # © @® #¢ e@ # # # # # @ # @# # @# # # # # # # @ @ 


ee e@8ee##eF ®eee#e8 @® @®# © @# ® # @® @® ® @® @® @®© @# @® @® @# @© @© @ @ 


BattalionName) <= 


aGun.BattalionName) 
BatteryName) <= 0 ) 


aGun.BatteryName) 
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eB ee A 5 Bs 
int operator == (GunDBC1s& aGun) 
ag Sg SE AS i a a 
{ 

if(!strcmp(BattalionName, aGun.BattalionName) ) 

if(!strcemp(BatteryName, aGun.BatteryName) ) 
if (GunNo == aGun.GunNo) 
pee Bog) game a 

return Q; 
} 
//---functions to access the data members 
char *GetBattalionName () {return BattalionName; } 
char *GetBatteryName () {return BatteryName; } 
short GetGunNo() {return GunNo; } 
long GetCoorEast () {return CoorEast; } 
long GetCoorNorth() {return CoorNorth: } 
ete GetHeight () {return Height; } 
BOOL isMainGun() {return MainGun; } 
char *GetModel () {return Model; } 
long GetMaxRange () {return MaxRange; } 
Deke GetMaxRightDeflection() {return MaxRightDeflection; } 
ane GetMaxLeftDeflection() {return MaxLeftDeflection; } 


ety C. eeeGcommonorientationbDeflection() {return 
CommonOrientationDeflection; } 


igus GetOrientationDeflection() {return OrientationDeflection; } 

//---functions to set the data members 

void SetBattalionName(char *in) {strcpy (BattalionName, in) ;} 

void SetBatteryName(char *in) {strcpy(BatteryName, in) ;} 

void SetGunNo(short in) (Gunes — in} 

void SetCoorEast(long in) {Georhast = in; } 

void SetCoorNorth(long in) {CoorNorth = in;} 

void SetHeight (int in) (Heveht = 11) 

void SetMainGun(BOOL in) {MainGun = in; } 

void SetModel(char *in) {strcpy (Model, in);} 

void SetMaxRange(long in) {MaxRange = in;} 

void SetMaxLeftDeflection(int in) i(Maxijereberlection =| in: } 

void SetMaxRightDeflection(int in) {MaxRightDeflection = in;} 

void SetCommonOrientationDeflection(int in) 
{CommonOrientationDeflection = in;} 

void SetOrientationDeflection(int in) {OrlentationDericetion = 
inh} 


//resets all data members 


{ 
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BattalionName [0] = NUE 
BatteryName [0] = NOULE- 
GunNo =: "OE= 
CoorEFast = Oe. 
CoorNoreln = 40) 
Height = 20; 
MainGun = J 
strcepy (Model, ”*[-]7); 

MaxRange =; 
MaxRightDeflection 6) 
MaxLeftDeflection = is 
CommonOrientationDeflection = 0; 
OrientationDeflection =r 


oe 


#endiff _GUNDB_H 


Listing B.7: INFO.H header file 





[ [RRR ERR RRR EER REREEREEEERE EEE REREAKRERRREKRERKREE EE EY ee 


77 

77 sD GuEOL Aa) 

i7 

// header file for the classes SelectionToolCls 
Toh DistanceToolCls 
77 NewToolCls 

Ve NewTToolCls 

(a SearchToolCls 
Jy PickToolCls 

v7 InfowndCls 

7 ToolBarWndCls 
io CanvasWndCls 


[ [RRR RRR RERRERERRERARER AKER KARE E S A Rt eee 


#ifndef __INFO_H 
# define __INFO_H 


//note that the following code is executed only 
//if this file has not been previously included 


#incluide “chare on. 


_CLASSDEF (SelectionToolCls) 
// class SelectionToolcls 
// Purpose : Base class for selection button classes. 


Hos 
// Notes 
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WE 
Mmepeooyright: Copyright (c) 1993, Mustafa ESER 
ay, All Rights Reserved 


Glass SelectionToolCcls 


{ 
protected: 


HCURSOR hCursor; 
public: 


SeiieectionToolCls() {} 
long FindDistance(long, long, long, long); 
fee rinagAzimuth(long, long, long, long); 


//abstract methods, which will be implemented in derived classes. 
virtual void DoMouseDown(long, long) {} 

virtual void DoMouseMove(long, long) {} 

virtual HCURSOR GetCursor () {return hCursor; } 

virtual void Reset () {} 


_CLASSDEF (DistanceTool1Cls) 


0 SS SS ee 
// class DistanceToolCls 
// 
// Purpose : Behaves for the distance button. 
vf 
// Notes 
as 
Mmepeopyright: Copyright (c) 1993, Mustafa ESER 
ja All Rights Reserved 
| i 
class DistanceToolCls : public SelectionToolCls 
{ 
private: 
BOOL ClickedBefore; , 
long 2a Cale 
long Distance; 
long Azimuth; 
HCURSOR hCursorl, hCursor2; 
Public: 
DistanceToolCls(HCURSOR hC1, HCURSOR hC2); 
virtual void DoMouseDown(long X, long Y); 
virtual void DoMouseMove(long X, long Y); 
virtual HCURSOR GetCursor(); 
Virtual void Reset(); 
); 
_CLASSDEF (NewToolCcls) 
ft 
// class NewToolCls 
ii 
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// Purpose : Behaves for the new tool button. 
a! 

// Notes 

Tf 

// Copyright: Copyright (c) 1993, Mustafa ESER 
f/f All Rights Reserved 


class NewToolCls : public SelectionToolCls 
{ 


private: 
HCURSOR hCursorl1; 


public. 
NewToolCls (HCURSOR hCl1); 
virtual void DoMouseDown(long X, long Y); 
virtual void DoMouseMove(long X, long Y); 
virtual HCURSOR GetCursor() {returnencursorl-) 
virtual void Reset(); 


_CLASSDEF (NewTToolCls) 


| ee 
// class NewTToolCls 
ae 
// Purpose : Behaves for the new from tool button. 
fa 
// Notes 
lee 
// Copyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 
ee ee ee ee 
class NewTToolCls : public SelectionToolCls 
{ 
private: 
BOOL ClickedBefore; 
long el oN es 
HCURSOR hCursorl, hCursor2; 
long Distance; ‘4 
int Azimuth; 
Dub ies 


NewTToolCls (HCURSOR hC1, HCURSOR hC2); 
virtual void DoMouseDown(long X, long Y); 
virtual void DoMouseMove(long X, long Y); 
virtual HCURSOR GetCursor(); 

virtual void Reset(); 


_CLASSDEF (SearchToolCls) 


yi i 
// class SearchToolCls 

a 

// Purpose : Behaves for the search button. 


a 
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// 

[memeorvright: Copyright (c) 1993, Mustafa ESER 

i / All Rights Reserved 

ee eee eee SS SS SS SS Se eS ee Se SS Se SS SS SH == 


class SearchToolCls : public SelectionToolCls 


( 


private: 
HCURSOR hCursor1; 
public: 


SearchToolCls(HCURSOR hCl1); 

virtual void DoMouseDown(long X, long Y); 

virtual void DoMouseMove(long X, long Y); 

virtual HCURSOR GetCursor() {return hCcursor! = } 
virtual void Reset(); 


_CLASSDEF (PickToolCls) 
// class PickToolCls 


// Purpose : Behaves for the pick tool button. 


es 
femweepyright: Copyright (c) 1993, Mustafa ESER 
// All Rights Reserved 


class PickToolCls : public SelectionToolCls 
{ 


private: 
HCURSOR hCursorl1; 
Rival ic : 


PickToolCls(HCURSOR hC1); 

virtual void DoMouseDown(long X, long Y); 

Virtual void DoMouseMove(long X, long Y); 

virtual HCURSOR GetCursor() (return eneursorl > } 
virtual void Reset(); 


_CLASSDEF (InfoWndCls) 


— ee wc cc cr cr cr cr rw cc cw cc cc cc cc cw ew we ee ee wo 
—_—o ec rc cr cr cr cr cr cr cr cr cr cc cr cr cr cr cm cr cc cr ce ce ce ec ce ee ee ee ee ee ee ei 


// class InfoWndCcls 

ee 

// Purpose : Displays the info area at the bottom of the window. 
ee 

// Notes 

ls 

// Copyright: Copyright (c) 1993, Mustafa ESER 

i All Rights Reserved 
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class InfoWndCls : public TWindow 
{ 


PEI Vate: 


RECT WndRect ; 
PTScrollBar HorizantalScroll; 


public: 


InfoWndCls (PTWindowsObject AParent, LPSTR ATitle); 

~InfoWndcCls(); 

virtual void SetupWindow() ; 

virtual void Paint (HDC PaintDC, PAINTSTRUCTS&) ; 

virtual void WMSize(TMessage&) ; 

virtual void WMLButtonDown(TMessage &Msg) = [WM_FIRST + 
WM_LBUTTONDOWN ] ; 

virtual void MenuONE(RTMessage) 

virtual void MenuTWO(RTMessage) 

virtual void MenuTHREE(RTMessage) 

virtual void MenuFOUR(RTMessage) 

virtual void MenuFIVE(RTMessage) [CM_FIRST CM_SCALEFIVE] ; 

virtual void MenuSIX(RTMessage) [CM_FIRST CM_SCALESIX] ; 

virtual void WMHScroll(RTMessage Msg); 

virtual void DisplayInfo(char *); 

virtual void DrawScaleButton(); 


2 


[CM_FIRST + CM_SCALEONE] ; 
[CM_FIRST + CM_SCALETWO] ; 
[CM_FIRST + CM_SCALETHREE] ; 
[CM_FIRST + CM_SCALEFOUR] ; 
a 
+ 


_CLASSDEF (ToolBarWndCl1s) 


| 
// class ToolBarWndCls 
io, 
// Purpose : Displays the tool bar area at the right of the window. 
ff 
// Notes : 
ee 
// Copyright: Copyright (c) 1993, Mustafa ESER 
ii All Rights Reserved 
i 
class ToolBarWndCls : public TWindow ° 
{ 
private: 
RECT WndRect; 
PTScrollBar VerticalScroll; 
HBITMAP hBitmap[5]; 
HCURSOR hCursorFrom, hCursorTo, NHCursorPick- 


PSelectionToolCls SelectionArray [5]; 
bublac- 


ToolBarWndCls (PTWindowsObject AParent, LPSTR ATitle); 

~ToolBarWndCls(); 

virtual void SetupWindow() ; 

virtual void Paint(HDC PaintDC, PAINTSTRUCTS&) ; 

virtual void WMSize(TMessage&) ; 

virtual void WMVScroll(RTMessage Msg); 

virtual void WMLButtonDown(TMessage &Msg) = [WM_FIRST + 
WM_LBUTTONDOWN ] ; 
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_CLASSDEF (CanvasWndCls) 
// class CanvasWndCls 


// Purpose : Displays the drawing area which holds targets, gun 
// positions etc. 


[emeepyright: Copyright (c) 1993, Mustafa ESER 
77 All Rights Reserved 


class CanvasWndCls : public TWindow 


{ 


private: 


RECT WndRect; 
HBITMAP TickMarkBmp; 
HBITMAP TickMarkMask; 


public: 


CanvasWndCls(PTWindowsObject AParent, LPSTR ATitle)j; 

~CanvasWndCls(); 

virtual LPSTR GetClassName(); 

virtual void SetupWindow() ; 

Virtual void Paint( HDC PaintDC, PAINTSTRUCTS) ; 

Virtual void WMLButtonDown(TMessage &Msg) = [WM_FIRST + 
WM_LBUTTONDOWN] ; 
virtual void WMMouseMove(TMessage &Msg) 
virtual void WMSetCursor(TMessage &Msg) 
virtual BOOL ReadTargetData(); 
virtual BOOL ReadGunData(); 
fiteuial void DisplayGuns (HDC hDC) ; 
virtual void DisplayGunLabels (HDC); 
Virtual void DrawGrids (HDC hDC, RECT Rect); 
virtual void DisplayTargets(HDC hDC); 
virtual void DisplayTargetLabels (HDC hDC); 
virtual void DrawLocationLines(long, long); 
Virtual void TestConstraints(); 


[WM_FIRST + WM_MOUSEMOVE] ; 
[WM_FIRST + WM_SETCURSOR] ; 


¢ 


ee 


#endif _ INFO_H 


Listing B.8: TARGETDB.H header file 





J [BRR ERR RK KEK KEKE KEKE KK REE EK EK KKK KEK KEK KKK KEKE KKK KEKKEKEKEKREKKKEKKEE 


i7 targetdb.h 


// header file for the class TargetDBCls 


[ [BRR RK KKK KEKE KKKEKKEKKEKKEK KEK KK KEKE KKK KKK KEKE KKKEKKKEKEKKKKKKKKKKKKKKEKKKKKK KS 
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#ifndef _TARGETDB_H 
# define _TARGETDB_H 


//note that the following code is executed only 
//if this file has not been previously included 


#include <string.h> 


#defineMAXTARGETNOLEN1 0 


#define MAXCOORLEN 10 
#def1neMAXDESLEN 50 
#defineMAXCATLEN 50 
#define MAXBUF 50 


_CLASSDEF (TargetDBCls) 
// class TargetDBCls 
// Purpose : Serves as database management class for target database. 


// Notes 

es 

// Copyright: Copyright (c) 1993, Mustafa ESER 
i 7 All Rights Reserved 


class TargetDBCls 
{ 


private: 


char TargetNo[MAXTARGETNOLEN] ; 
long CoorEast; 

long |GeorNeren- 

eeke Height; 

char Description [{MAXDESLEN] ; 
char Category [MAXCATLEN] ; 


public 

sere eee eee eee rs OO OE Bee eS eee 
TargetDBCls() 
VL ERA we LER le ee AO 
{ 

TargetNo[0] = NULL: 

CoorFast =.0; 

CoorNorth = 0% 

Height = <0); 

Description |0) 9= NULL: 

Category [0] = NUE: 
} 
Ee nS ES BBWS ORS cw 


TargerDECls (char tn. 
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os SGN ty eS 0 yaa 
{ 

strepy(TargetNo, tn); 

CoorEast = Ca: 

CoorNorth — 910 

Height = he > 


strcepy (Description, des) ; 
Serepy (Category, cat); 


ot See od oS el 9 9) SIS csi oe 0 0 4 So Hele ee ele sew eo ee we ee 
a sg re 616 6S BINNS les ee rer 


Secepy(TargetNo, T.TargetNo) ; 
CoorEast TPeCoorenast; 

CoorNorth MecoorNornt ii; 

Height T.Height; 

eiemepy (Description, T.Description); 
strepy (Category, T.Category); 


ve / eo ec ef ee © © © © © © ee @ a ed 
. 


ne BRS 6 5 a Se See ee Ae a ee ee ee ee 


//assignment operator 

{ 
strepy (TargetNo, T.TargetNo) ; 
CoorEast De eeoorbast-: 
CoorNorth tT CoorNorth- 
Hercht T.Height; 
strcpy (Description, T.Description) ; 
serepy (Category, T.Category) ; 
return *this; 


af 


oe fF fF @ ef & & &@ # &@© @© @ @ @ @ @ &@ &@8 @ @ © &@& &@©® &@ &@® @® © &@© @ @ @ © © © © © &©& © &@ @ @& &@ @ &@ &@ &@ @® @ &@® &@© ®@® @ @ @ © © © @© @ &@© © &@ @ 


// 


baa 


return stremp(GetTargetNo(), aTarget.GetTargetNo()) < 0; 
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Lian cece cet en ties 005 6 ee 5 6 ow ee 5 elles oe Sect ie ne er ee 


| |v icc eb 6 EWE ee He Nee a 3 6 Em ee ey SS ee Sa 
{ 

return strcemp(GetTargetNo(), aTarget.GetTargetNo()) > 0; 
} 
TD oan oo 6 ee as ee ee eu 8 ele ae cme eer 
int operator <= (TargetDBCls& aTarget) 
TL Liacicn ccc ee bs ee we © 6 6 le MINTS ee ale 5a eer meie ln ene Ser ate etme nen eae ae 
{ 

return strcemp(GetTargetNo(), aTarget.GetTargetNo()) <= 0; 
} 
Vb ivan ce ewe wwe bw ee 6 ae Soe oe wm See © So Cie a ree Nee re neers 
int operator == (TargetDBCls& aTarget) 
Vd vaca ne bee bee weer el eee Sele wwe ee © ee ae ie ee 
{ 

return stremp(GetTargetNo(), aTarget.GetTargetNo()) == 0; 
} 
//---functions to access the data members 
char* GetTargetNo() {return TargetNo; } 
long GetCoorEast () {return CoorEast; } 


long GetCoorNorth() {return CoorNorth; } 

ine GetHeight () {return Height; } 

char* GetDescription() {return Description; } 

char* GetCategory () {return Category; } 
//---functions to set the data members 

void SetTargetNo(char* tn) {strcepy(TargetNo, tn) ;} 
void SetCoorEast (long east) {CoorEast = east; } 

void SetCoorNorth(long north) {CoonrNorth =snerth 
void SetHeight (int height) {Height = height; } 

void SetDescription(char* des) {strcepy(Description, des) ;} 
void SetCategory(char* cat) {strcepy(Category, cat); } 


VL aww cee 6 oe Ua Ou ee EW e © eas Cree eee ee 
void Reset () 
ee rr i ee wee 
{ 

TargetNo[0}] =) NUL; 

CoorEast — AY 8) 

CoorNorth =0- 

Height = 0). 

Description[0} = NULL; 

Category [0] = NULL; 


ie 


#endif _TARGETDB_H 
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APPENDIX C. (DATABASE HEADER FILES LISTINGS) 


Listing C.1: DBGUN.H header file 





nn Pe ean n ees eee en ON EERE RE EERE RE EER AER ERE EERE ERE REE 


if dbgun.h 


// header file for the class DBGunCls 


eee Oo ee ent KT AERA K RA ARERR EERE REAR ER ER ER © 


#ifndef _DBGUN_H 
B define ~DBGUN_H 


#include "WStr.h” 
#include “Paradox.h’” 


#define MAXNAMELEN 10 
#define MAXMODELLEN 30 


_CLASSDEF (DBGunCls) 
(in SS SS SS SS SS 
// class DBGunCls 
iy 
// Purpose : Performs database management for guns. 
// Notes : 
feemeopyraghnt: Copyright (c) 1993, Mustafa ESER 
Ve: All Rights Reserved 
LO a ee et 
class DBGunCls 
{ 
private: ° 
o/7#1 
char BattalionName [MAXNAMELEN] ; 
char BatteryName [MAXNAMELEN] ; 
short GunNo; 
long CoorEast; 
long COOrNGren ; 
Ber Height; 
BOOL MainGun; 
char Model [MAXMODELLEN] ; 
long MaxRange; 
ee MaxRightDeflection; 
feral te MaxLeftDeflection; 
ert CommonOrientationDeflection; 
int OrientationDeflection; 
char FiringTableName [MAXNAMELEN] ; 
//#14 


//Paradox table info 
ParadoxTable TableGuns; 


Al 


Dat nFields; 


LPSTR Names [14]; 
LPSTR Types [14]; 
protected: 


void RecordToBuffer(); 
publ ve: 


DBGunCls(LPSTR TableName) ; 
~DBGunCls(); 


BOOL ReadFirst(); 
BOOL ReadLast () ; 
BOOL ReadNext (); 
BOOL ReadPrev(); 
BOOL isTableEmpty (); 
BOOL isLast(); 


BOOL AddRecord(); 

BOOL UpdateRecord() ; 

BOOL DeleteRecord() ; 

BOOL SearchByKey(char *Btn, char *Btr, int Gun); 


void Reset(); 
//functions to access the data members 


char *GetBattalionName () {return BattalionName; } 
void SetBattalionName(char *in) {strcepy(BattalionName, in) ;} 


char *GetBatteryName() {return BatteryName; } 

void SetBatteryName(char *in) {strcepy(BatteryName, in); } 
short GetGunNo() {return GunNo; } 

void SetGunNo(short in) {GunNo = in; } 

long GetCoorEast () {return CoorEast; ) 

void SetCoorEast (long in) {CoorEast = in; } 

long GetCoorNorth() {return CoorNorth; } 

void SetCoorNorth( long 1) {CeocrNortns= ins 

int GetHeight () {return Height; } 

void SetHeight(int in) {Height = in;} 

BOOL isMainGun() {return MainGun; } 

void SetMainGun(BOOL in) {MainGun =" in;) 

char *GetModel () {return Model; } 

void SetModel(char *in) {strcepy (Model, in);)} 

long GetMaxRange() {return MaxRange; } 

void SetMaxRange(long in) {MaxRange = in;} 

Init GetMaxRightDeflection() {return MaxRightDeflection; } 


void SetMaxLeftDeflection(int in) {MaxLeftDeflection = in;} 


ele GetMaxLeftDeflection() {return MaxLeftDeflection; } 
void SetMaxRightDeflection(int in) {MaxRightDeflection = in;} 
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none GetCommonOrientation() 
{return CommonOrientationDeflection; } 
void SetCommonOrientation(int in) 


{CommonOrientationDeflection = in; } 
for GetOrientationDeflection() {return OrientationDeflection; } 
void SetOrientationDeflection(int in) {OrientationDeflection = in;} 
char *GetFiringTableName () {return FiringTableName; } 
void SetFiringTableName(char *fn) {strcepy (FiringTableName, fn); } 


ee 


#endif _DBGUN_H 


Listing C.2: DBTARGET.H header file 





iM aeaieian tanith Ate KORA KERR KEKE ERR KEKE ER RE R ER ERERE RRR EKEEEE 


Lf 

1a, dbtarget.h 
ae 

// hneader file for the class DBTargetCls 


ae ne a eR ER EERE RK REE ERK EKER REEEEAKEAEERE KK 


#ifndef _DBTARGET_H 
- define _DBTARGET_H 


#include "WStr.h” 
#include ”Paradox.h” 


#define SUCCESS Al 
#define FAIL 0 
#define MAXTARGETNOLEN- 10 
#define MAXCOORLEN 10 ’ 
#define MAXDESLEN 5) 
#define MAXCATLEN 50 
#define MAXBUF 50) 


_CLASSDEF (DBTargetCls) 


i 
// class DBTargetCls 

ey 

// Purpose : Performs database management for targets. 

// Notes 

// Copyright: Copyright (c) 1993, Mustafa ESER 

ay All Rights Reserved 
ee 


class DBTargetCls 
{ 


private: 
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char 


double 
double 
double 


char 
char 


TargetNo [MAXTARGETNOLEN] ; 


CoorFast; 

CoorNoreh- 

Height; 

Description [MAXDESLEN] ; 
Category [MAXCATLEN] ; 


//Paradox table info 
ParadoxTable TableTargets; 


int 


eo wk 
Deo 


nFields; 
Names [6] ; 


Types [6]; 


protected: 


void 
void 


public: 


er 


RecordToBuffer(); 
BufferToRecord(); 


DBTargetCls(LPSTR TableName) ; 
~DBTargetCls(); 


BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 


BOOL 
BOOL 
BOOL 
BOOL 


void 


char 
void 


ReadFirst(); 
ReadLast (); 
ReadNext () ; 
ReadPrev() ; 
isTableEmpty (); 
isLast(); 


AddRecord() ; 
UpdateRecord() ; 
DeleteRecord(); 
SearchByKey (char *Key); 


Reset (); 


*Get TargetNo() 
SetTargetNo(char* tn) 


double GetCoorEast () 


Vord 


SetCoorEast (double east) (CoorEast = 


double GetCoorNorth () 


void 


SetCoorNorth(double north) {CoorNorth = 


double GetHeight () 


Vorld 


char 
void 


char 
void 


SetHeight (double height) {Height = 


*GetDescription () 


SetDescription(char* des) 


*GetCategory () 
SetCategory(char* cat) 


#endif _DBTARGET_H 


{return TargetNo; } 
{strcpy (TargetNo, 


{return CoorEast; } 
‘east; } 


Chas) 


{return (GeorNerth;} 


{return Height; } 
height; } 


Norell: 


{return Description; } 


{return Category; } 
{strecpy (Category, 
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{strcpy (Description, 


cat); 


des) ;} 


} 


Listing C.3: DBTBL_F.H header file 





Ce Rea eee RRA E KEEE AEE KEE EE EKER EREEEREKERAKKEKREEAKKK K 


ii 
v7 bebe ah 
oe 
// header file for the clas DBTable_F_Cls 


ieee cee KE ERE REE AE RR ERERE RARE EKER REREREKEREKRAEES 


#ifndef __DBTABLE F_H 
# define _ DBTABLE_F_H 


#include “WStr.h” 
#include *Paradox.h” 


_CLASSDEF (DBTable_F_Cls) 


a 
// class DBTable_F Cls 
V7 
// Purpose : Performs database management for Table F of firing table 
// Notes 
feemeopyright: Copyright (c) 1993, Mustafa ESER 
fa All Rights Reserved 
class DBTable_ F_ Cls 
{ 
private: 
double Range; //0 
double Elevation; ty ah 
double FSforGrazeBurst; HL GE 
double DFSperl10mDecHOB; he 
double DRperimilDElev; ee 
double Fork; TLS 
double TimeOfFlight; LPS ’ 
gdouble AzimuthCorrDrift; fae 
double AzimuthCorrCrossWind;//8 
double MuzzleVelocityDec; / 72 
double MuzzleVelocitylIinc; fe AG® 
double RangeWindHead; 7 ELL 
double RangeWindTail; Tel2 
double AirTempDec; fie 
double AirTempInc; //14 
double AirDensityDec; TEE News 
double AirDensityiInc; J//X6 


double ProjectileWeightDec; //17 
double ProjectileWeightInc; //18 


//Paradox table info 
ParadoxTable Table_F; 


gts nFields; 
LPSTR Names [18]; 
LPSTR Types[19]; 
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protected: 
vYOl1d RecordTosurtrer():. 
DUD Ge. 


DBTable_F_Cls(LPSTR TableName) ; 
~DBTable_F_Cls(); 


BOOL ReadFirst(); 
BOOL ReadLast (); 
BOOL ReadNext (); 
BOOL ReadPrev(); 
BOOL isTableEmpty (); 
BOOL isLast(); 

void Reset(); 


double FindElevation(double range) ; 


#endif __DBTABLE_F_H 


Listing C.4: PARADOX.H header file 





[LR RRR REE RARER ERK ER RR RRR RRR RR KR RR RR I ee 


oe 
fe paradox.h 
i7 


// neader file for database engine inclusions 
[ [RRR REE KRERKEKEERKEEREKEREKRERKEEKKEREERKKEREKKKRKEKKRERKKAKEXK EE © 7% 7 


#ifndef PARADOX_H 
5 define PARADOX _H 


include <alloc.h> 
include’ <strang.h= 
include “PdoxEnging.h” 
include “PdoxTable.h” 
include “PdoxRecord.h’” 


$e HE OE HEHE 


// Note the following code is only executed if 
// this file has not been previously included 


char *GetParadoxError (int nError) ; 


#endif 
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Listing C.5: PDOXENG.H header file 





ee EEE EKA RE EERE EERE AE KEEERAEKREREKRKEKEKKE SK 


ad 

ef pdoxeng.h 

7/ 

wee ader file for the class SelectionWndCls 


eee ee EEE EERE RE EERE RA EKEEKE 


#ifndef ParadoxEngine_H 
# define ParadoxEngine_H 


// Note the following code is only executed if 
// this file has not been previously included 


#include “pxengine.h’” 


#ifdef _ BORLANDC__ 

//PC computer specific includes 
8 include <owl.h> 
#endif 


#ifdef Unix 
// Unix computer specific includes 
#endif 


// class ParadoxEngine 
// Purpose 
// Notes 


// Copyright: Copyright (c) 1993, Mustafa ESER 
ae All Rights Reserved 


_CLASSDEF (ParadoxEngine) 
class ParadoxEngine 
tic: 
static Status; 
ParadoxEngine (LPSTR szAPlication) ; 


~ParadoxEngine (); 


ie; 


#endif ParadoxEngine_H 
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Listing C.6: PDOXREC.H header file 





J [BRR RRR RRR BR eR eee 


// 
// pdoxrec.h 


// header file for the class ParadoxRecord 
[LL BRRRERERRREREREEER REE WK ES RR RE eee 


#ifndef ParadoxRecord_H 
# define ParadoxRecord_H 


// Note the following code is only executed if 
// this file has not been previously included 


#include <ctype.h> 
#include “PxEngine.h’” 
#include "WStr.h” 


#ifdef _ BORLANDC__ : 

// PC computer specific includes 
#include <owl.h> 

#endif 


#ifdef Unix 
// Unix computer specific includes 
#Hendif 


_CLASSDEF (ParadoxTable) 
_CLASSDEF (ParadoxRecord) 


// class ParadoxRecord 

Vor 

// Purpose 

de 

// Notes 

la 

// Copyright: Copyright (c) 1993, Mustafa ESER 
ae All Rights Reserved 


class ParadoxRecord 
{ 


private: 


ParadoxTable ParentTable; 
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Public: 


RECORDHANDLE HRecord; 
intStatus; 


ParadoxRecord (ParadoxTable) ; 
Virtual ~ParadoxRecord (); 


wororawGet (void *, int BufferSizZe) ; 
void RaPut (void *, int BufferSize); 


WStr GetField (FIELDHANDLE FieldNumber) ; 

WStr GetField (LPSTR FieldName) ; 

void PutField (FIELDHANDLE FieldNumber, WStr); 
void PutField (LPSTR FieldName, WStr); 

int Update (); 


mit Add ()>; 
int Read (); 


#include ”“PdoxTable.h” 


#endif ParadoxRecord_H 


Listing C.7; PDOXTAB.H header file 


ea RR EERE RRR E EE RARER RARER REE KE 


Lf Pdoxtab.h 


// header file for the class ParadoxTable 


Ie A REE REE RE RRR REESE 


Cd 


#ifndef ParadoxTable_H 
# define ParadoxTable_H 


// Note the following code is only executed if 
// this file has not been previously included 


#include <DIR.H> 
#include “WStr.h” 
#include “pxengine.h” 
#include ”“PdoxEngine-h” 
#include ”PdoxRecord.h” 


#ifdef _ BORLANDC__ 
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// PC computer specific includes 
#include<owl .h> 
#endif 


#ifdef Unix 
// Unix computer specific includes 
#endif 


_CLASSDEF (ParadoxTable) 
ParadoxTable 


// Purpose 

ye 

// Notes : = 

// 

// Gopyrignt: Veep, e1qheee ero er 
All Rights Reserved 


Mustafa ESER 


class ParadoxTable 


‘ 
pub lac. 


intStatus; 
ParadoxRecord Record; 
TABLEHANDLE HTable; 


ParadoxTable (LPSTR TableName, 
2 one IndexField = 
Ine nFields = 0, 
char *Names[] = NULL, 
char” *Types | je=_ NUE eS 
virtual ~ParadoxTable (); 


0, 


void DeleteAll (); 

RECORDNUMBER TotalRecords (); 
RECORDNUMBER CurrentRecord (); ° 
void 
Vora 


RecordUpdate ( 


Be 
RecordDelete (); 


Voud 


void 
void 
wold 
void 
void 


void 
void 
void 
void 


void 


RecordAdd (); 


ReadFirst 
ReadLast /( 
ReadNext ( 
ReadPrev (); 

ReadRecord (RECORDNUMBER RecordNumber) ; 


( 
) 
) 


) * 
f 
‘ 
a 
‘ 


IndexDelete (char *Field); 
IndexDelete (FIELDHANDLE FieldNumber) ; 
IndexAdd (char *Field, int Mode = INCSECONDARY) ; 
IndexAdd (FIELDHANDLE FieldNumber, int Mode = INCSECONDARY) ; 
int Mode = 


Find (WStr Match, LPSTR FieldName, SEARCHERS. 


void Find (WStr Match, FIELDHANDLE FieldNumber, int Mode = SEARCHFIRST) ; 
a 
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radoxTable_H 





APPENDIX D. (SCREENS OF APPLICATIONS) 
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(OFire) First page of the Record of Fire screen. 
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Screen 4: (OFire) Call for fire dialog box. 
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Screen 5: (OFire) Fire order figioe box. 
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Screen 6: (OFire) Message to observer dialog box. 
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Screen 7: (OFire) Subsequent fire call dialog box. 
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Screen 8: (OFire) Time-on-target dialog boxes. The above dialog box set the time refering the 
present time, while the below one sets the exact time. 
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Screen 10: (OChart) Grid setup dialog box. 





Screen 11: (OChart) Both tartget and guns database dialog boxes. 
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Screen 13: (OChart) Gun display setup dialog box. 
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Screen 14: (OChart) Input inquiry dialog box. 





Screen 15: (OChart) Input inquiry dialog box (refering to a point) 
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Screen 16: (OChart) Target input dialog box. 


Azimuth : 1623 mils 


Distance : 3911 meters 





Screen 17: Azimuth and distance distance display dialog box. 
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Screen 18: (OChart) Gun input dialog box. 
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